Wenn GDB debuggen sagt mir folgende Fehlermeldung:C - Speicher kann nicht an der Adresse zugreifen
0x800c99ed00000001 < error: Cannot access memory at address 0x800c99ed00000001>
Der Fehler wird erzeugt, wenn ich einen Haltepunkt setzen, wenn ich ConvertByteArrayToFloat rufen beim Debuggen.
Aber das Programm beendet ohne ein Problem und gibt mir ein Ok-Ergebnis?
Meine Hauptdatei:
#include "Local.h"
int main(void) {
if(HandleReceivedMessages() == OP_COMPLETED){
printf("Main Completed \n");
} else {
printf("Main Failed \n");
}
return 0;
}
Local.h
#ifndef LOCAL_H_
#define LOCAL_H_
#include "Common.h"
T_OP_STATUS HandleReceivedMessages(void);
#endif
Local.c
#include "Handler.h"
#include "Local.h"
uint8_t message[] = {0x86, 0x9a, 0xa0, 0x00, 0x00, 0x01, 0x01, 0x07, 0x00, 0x10, 0x4a, 0x00, 0x00, 0x00, 0x00, 0xe1};
uint8_t length = 16;
T_OP_STATUS HandleReceivedMessages(void) {
if(HandleResponseMessage(message, length) == STATUS_SUCCESS) {
printf("Completed from Local \n");
return OP_COMPLETED;
} else {
printf("Failed from Local \n");
return OP_FAILED;
}
}
handler.h
#ifndef HANDLER_H_
#define HANDLER_H_
#include "Common.h"
T_MESSAGE_STATUS HandleResponseMessage(uint8_t *requestData, uint8_t msgLength);
#endif /* HANDLER_H_ */
Handler.c
#include "Handler.h"
#include <string.h>
static uint8_t rawRequestData[BUFFER_WIRED_SIZE];
static float TempFloat = 0;
T_MESSAGE_STATUS HandleCmd(uint16_t cmdNumber, uint8_t rawDataLength,
uint8_t *rawDataPtr) {
switch (cmdNumber) {
case 1:
TempFloat = ConvertByteArrayToFloat(&rawDataPtr[3]);
printf("The value of the float is : %f \n", TempFloat);
return STATUS_SUCCESS;
default:
break;
}
return STATUS_NOT_IMPLEMENTED;
}
T_MESSAGE_STATUS HandleResponseMessage(uint8_t *message,
uint8_t msgLength) {
uint8_t cmdNumber, dataLength, startOfData;
// Check the delimiter.
if (message[0] & INDICATOR_UNIQUE_ADDRESS) {
cmdNumber = message[6];
dataLength = message[7];
startOfData = 8;
} else {
cmdNumber = message[2];
dataLength = message[3];
startOfData = 4;
}
// we copy only the real data from the command response
memcpy(&rawRequestData, message + startOfData, dataLength);
return HandleCmd(cmdNumber, dataLength, rawRequestData);
}
COMMON.H
#ifndef COMMON_H_
#define COMMON_H_
#include <stdint.h>
#include <stdio.h>
#define BUFFER_WIRED_SIZE 128
#define INDICATOR_UNIQUE_ADDRESS 0x80
typedef enum {
OP_FAILED,
OP_COMPLETED,
}T_OP_STATUS;
typedef enum
{
STATUS_SUCCESS,
STATUS_NOT_IMPLEMENTED,
} T_MESSAGE_STATUS;
float ConvertByteArrayToFloat(uint8_t *data);
#endif /* COMMON_H_ */
common.c
#include "Common.h"
float ConvertByteArrayToFloat(uint8_t *data) {
union {
uint8_t tmpArray[4];
float tmpFloat;
} value;
value.tmpArray[0] = data[3];
value.tmpArray[1] = data[2];
value.tmpArray[2] = data[1];
value.tmpArray[3] = data[0];
return value.tmpFloat;
}
Dies ist die min-Version (es macht eine Menge Dinge wie das Format der Überprüfung Nachricht, CRC, etc ..) aber geht von Anfang bis Ende durch all diese Dateien.
Ich arbeite an einer Embedded-Plattform und beim Debuggen in meinem Mikrocontroller und Aufruf der Funktion ConvertByteArrayToFloat springt mein Programm zu einem anderen Teil meines Codes und dann stürzt es den Mikrocontroller ab.
Ich versuche, den Fehler in meinem Computer ohne den Mikrocontroller neu zu erstellen, und ich fand den Fehler an der Spitze.
Was ist Ihr Mikrocontroller? Ist es Big-Endian oder Little-Endian? Sie benötigen/haben eine Funktion, die das Gegenteil von "ConvertByteArrayToFloat" (z. B. "ConvertFloatToByteArray") ist, das nicht gezeigt wird, um die Nachrichten zu erzeugen, die "ConvertByteArrayToFloat" decodiert. Sie können für die falsche Endianness hardwiring sein und die Konvertierungsfunktion explodiert, wenn der Float zurückgegeben wird. Das heißt, fest verdrahtet für [say] x86, also funktioniert es dort, aber Controller kann big-endian sein [oder umgekehrt] –
Das Mikro ist Little Endian, aber die Sache ist, dass es in meinem Mikro nicht den Breakpoint im Inneren trifft ConvertByteArrayToFloat, wenn es diese Anweisung erreicht, springt es zu einem anderen nicht verwandten Teil des Codes und dann stürzt es einfach ab und geht in HardFault. Ja, es gibt auch eine ConvertFloatToByteArray, aber es wird nicht für den Moment verwendet, da ich gerade versuche, Werte zu lesen und nicht zu schreiben. – IzonFreak
Sounds wie UB verursacht durch frühere UB. Ich sah die '+ 3', die sich entspannen ließ [aber dachte, du hättest das bereits überprüft]. Könnte es einen anderen Ort geben, der früher einen Puffer überläuft (d. H. Etwas Schreibtisch überprüfen), der dieses spätere Problem verursacht? Stapelüberlauf durch unbeabsichtigte Rekursion? Auf dem uC, könnte Interrupt Vektoren [welche bkpt braucht] korrumpiert werden? Versuchen Sie einen Aufruf der Konvertierungsfunktion während der frühen Initialisierung, um zu beweisen, dass es mindestens einmal funktioniert. Dann pfeffert man ihn künstlich an (dh mach es zum Kanarienvogel in der Kohlemine). Können Sie den Code (vs. bkpt) _step_? –