I've been working with stm32f103, now I'm trying to lunch some codes on stm32f407.
To communicate through USART interface I use fifo query in form of structure, defined in header file:
#define FIFO_BUF_SIZE 128
typedef struct {
char data[FIFO_BUF_SIZE];
uint16_t startIndex;
uint16_t endIndex;
}FIFO, *ptrFIFO;
Global declaration of this structure in source file:
FIFO RX_Buff={{},0,0};
FIFO TX_Buff={{},0,0};
Now I want to put data from char array to fifo query:
void USART_PrintData(USART_TypeDef * USART, char str[]){
ptrFIFO pTX = &TX_Buff;
int i=0;
while(str[i]!='\0'){
FIFO_Put(pTX, str[i]);
i++;
}
//here in working program is code for sending data
//deleted from program for tests
}
void FIFO_Put(ptrFIFO fifo, char data){
uint16_t tmp;
tmp = fifo->startIndex;
fifo->data[tmp]=data;
tmp = (tmp+1)%(FIFO_BUF_SIZE-1);
fifo->startIndex=tmp;
}
This code has been worked on stm32f103 but won't on f407. After last sign passed to FIFO_Put() and write to fifo query, programm go to Default_Handler or strange address in memory (depends of humor), but when I using this structure directly it works fine:
void FIFO_Put(char data){
uint16_t tmp;
tmp = TX_Buff.startIndex;
TX_Buff.data[tmp]=data;
tmp = (tmp+1)%(FIFO_BUF_SIZE-1);
TX_Buff.startIndex=tmp;
}
I have no idea what's wrong.
Thanks for any help.
I've tried to debug, and the problem is in last line in function FIFO_Put():
fifo->startIndex=tmp;
When function putting last sign to fifo, after last line program jump to default_handler.
If I comment this line, program works fine.
Check the program stack size - from my experience, such kind of undefined behavior may be caused by stack overflow.
Related
In a program to erase and write into flash, I donot understand the lines
struct kinetis_flash *kf = calloc(1, sizeof(*kf));
struct target_flash *f = &kf->f;
from the below section of the code. And the whole program can be found at https://github.com/blacksphere/blackmagic/blob/master/src/target/kinetis.c
struct kinetis_flash {
struct target_flash f;
uint8_t write_len;
};
static void kl_gen_add_flash(target *t, uint32_t addr, size_t length,
size_t erasesize, size_t write_len)
{
struct kinetis_flash *kf = calloc(1, sizeof(*kf));
struct target_flash *f = &kf->f;
f->start = addr;
f->length = length;
f->blocksize = erasesize;
f->erase = kl_gen_flash_erase;
f->write = kl_gen_flash_write;
f->done = kl_gen_flash_done;
f->erased = 0xff;
kf->write_len = write_len;
target_add_flash(t, f);
}
It would be great if someone helps me understanding above tw lines, thanks in advance.Many targets for example KL25, K22, K64 can be accordingly used what i understood from the project. Are those two lines storing target specific specifications for flash?
In general we donot need to allocate any space for flash right using calloc or malloc like we do it for RAM.
The code in question extends GDB, allowing it to use various JTAG or Serial Wire interfaces to program and debug certain ARM devices. Identifying the attached devices flash device is a time consuming and disruptive (as-in can't run device code) task, so you only want to do it once, hence the local RAM allocation for storing the type and current state of the attached flash.
This line
struct kinetis_flash *kf = calloc(1, sizeof(*kf));
is a dynamic allocation of a struct kinetis_flash somewhere in RAM. It's probably used for holding information about a flash device present in the system.
This line
struct target_flash *f = &kf->f;
makes f point to the struct target_flash - named f - inside struct kinetis_flash so that you can write to it using f->some_var = ...
So the whole function is simply creating and initializing an object of type struct kinetis_flash
Though the code is correct, it's (IMO) a bit confusing to have a variable f pointing to f inside a struct. Perhaps a name like ptr_f would be more clear.
Also notice that the code is equivalent to:
static void kl_gen_add_flash(target *t, uint32_t addr, size_t length,
size_t erasesize, size_t write_len)
{
struct kinetis_flash *kf = calloc(1, sizeof(*kf));
kf->f.start = addr;
kf->f.length = length;
...
}
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I am writing a driver for FRAM for a robot, and all of a sudden I started getting this error:
C:\Users\james\AppData\Local\Temp\cciezvMm.o: In function `_FRAM_driver_setup':
(.text+0x0): multiple definition of `_FRAM_driver_setup'
cmm/FRAM_driver.o:(.text+0x0): first defined here
C:\Users\james\AppData\Local\Temp\cciezvMm.o: In function `_FRAM_log_data':
(.text+0xf): multiple definition of `_FRAM_log_data'
cmm/FRAM_driver.o:(.text+0xf): first defined here
C:\Users\james\AppData\Local\Temp\cciezvMm.o: In function `_FRAM_read_data':
(.text+0x7a): multiple definition of `_FRAM_read_data'
cmm/FRAM_driver.o:(.text+0x7a): first defined here
collect2: ld returned 1 exit status
Done. Build Failed!
I am not sure what brought this about, but I have not been able to find multiple definitions in my code. Here is the header file:
#ifndef FRAM_DRIVER_H_
#define FRAM_DRIVER_H_
#include "simpletools.h"
typedef struct FRAM_driver_type {
i2c* busID;
} FRAM_driver_type;
void FRAM_driver_setup(FRAM_driver_type* ptr, int sclPin, int sdaPin,
int sclDrive);
void FRAM_log_data(unsigned char* string, FRAM_driver_type* ptr);
void FRAM_read(FRAM_driver_type* ptr);
#endif
Here is the c file:
#include "FRAM_driver.h"
#define FRAM_DEFAULT_ADDR (0x50)
#define FRAM_MAX_MEM_ADDRESS (0x00)
#define FRAM_FIRST_MEM_ADDR (0x01)
#define FRAM_ADDR_SIZE ( 2 )
#define FRAM_DATA_SIZE ( 1 )
#define INT_SIZE ( 1 )
void FRAM_driver_setup(FRAM_driver_type* ptr, int sclPin, int sdaPin,
int sclDrive){
ptr->busID = i2c_newbus(sclPin, sdaPin, sclDrive);
}
void FRAM_log_data(unsigned char* data, FRAM_driver_type* ptr){
// Create a static integer initialized to the first memory address of the
// FRAM. It is 0x01 instead of 0x00 because 0x00 is going to be used to
// store the last memory adress being used. Also, create the int data_Size
// and set it equal to the length of the string plus one.
//
static int mem_Addr = FRAM_FIRST_MEM_ADDR;
int data_Size = strlen(data) + 1;
// Send the size of the data being sent to the next available memory
// address. This allows the FRAM_read_data funtion to know what size of
// data to read. Then increment up by one memory address.
//
i2c_out(ptr->busID, FRAM_DEFAULT_ADDR, mem_Addr, FRAM_ADDR_SIZE, data_Size,
INT_SIZE);
while(i2c_busy(ptr->busID, FRAM_DEFAULT_ADDR));
mem_Addr += 0x01;
// Write data to the next address when the FRAM is not busy, then increment
// the memory address by one again.
//
i2c_out(ptr->busID, FRAM_DEFAULT_ADDR, mem_Addr, FRAM_ADDR_SIZE, data,
data_Size);
while(i2c_busy(ptr->busID, FRAM_DEFAULT_ADDR));
mem_Addr += 0x01;
// Write the last memory address used to the first memory address of the
// FRAM. Then wait for the FRAM to not be busy.
//
i2c_out(ptr->busID, FRAM_DEFAULT_ADDR, FRAM_FIRST_MEM_ADDR, FRAM_ADDR_SIZE,
mem_Addr, INT_SIZE);
while(i2c_busy(ptr->busID, FRAM_DEFAULT_ADDR));
}
void FRAM_read_data(FRAM_driver_type* ptr){
// Initialize unsigned characters to receive data from i2c_in.
//
unsigned char logged_Data = 1;
unsigned char logged_Data_Size;
unsigned char last_Memory_Address;
// Get the last memory address written to from FRAM_MAX_MEM_ADDRESS and
// store it in last_Memory_Address.
//
i2c_in(ptr->busID, FRAM_DEFAULT_ADDR, FRAM_MAX_MEM_ADDRESS, FRAM_ADDR_SIZE,
&last_Memory_Address, INT_SIZE);
while(i2c_busy(ptr->busID, FRAM_DEFAULT_ADDR));
// Loop through all of the filled memory addresses in the FRAM and print
// the logged data in each address.
//
for (int i = FRAM_FIRST_MEM_ADDR; i <= last_Memory_Address; i+=2){
// Get the data_Size from the odd memory address and store it in
// logged_Data_Size. Then wait until the FRAM isn't busy.
//
i2c_in(ptr->busID, i, FRAM_FIRST_MEM_ADDR,
FRAM_ADDR_SIZE, &logged_Data_Size, INT_SIZE);
while(i2c_busy(ptr->busID, FRAM_DEFAULT_ADDR));
// Use logged_Data_Size to store the data to logged_Data and then print
// the data. Wait until the FRAM isn't busy.
//
i2c_in(ptr->busID, i++, FRAM_FIRST_MEM_ADDR,
FRAM_ADDR_SIZE, &logged_Data, logged_Data_Size);
print("Log: %d \n", logged_Data);
while(i2c_busy(ptr->busID, FRAM_DEFAULT_ADDR));
}
}
Lastly, here is the testbench file:
#include "FRAM_driver.h"
#define FRAM_SCL_PIN 28
#define FRAM_SDA_PIN 29
static FRAM_driver_type fram_obj;
int main() {
const unsigned char* data = 2;
FRAM_driver_setup(&fram_obj, FRAM_SCL_PIN, FRAM_SDA_PIN, 0);
FRAM_log_data(data , &fram_obj);
FRAM_read_data(&fram_obj);
}
Any help would be greatly appreciated. Also, I am using simpleIDE and the simpletools library for a Propeller microcontroller.
C:\Users\james\AppData\Local\Temp\cciezvMm.o: In function '_FRAM_driver_setup:
(.text+0x0): multiple definition of '_FRAM_driver_setup'
cmm/FRAM_driver.o:(.text+0x0): first defined here
This error means that your link line is referencing FRAM_driver.c twice, and looks something like this:
gcc ... cmm/FRAM_driver.o ... cmm/FRAM_driver.c ...
Don't do that -- it obviously can't work.
SimpleIDE was including a backup of a file that was not included in the project directories. Actually, I couldn't find it anywhere. It was as if it was creating the backup copy of the code I was working on and then storing it in a temporary location whenever I ran the code. The file was removed from the SimpleIDE project files and then it worked.
I am working on an embedded platform which does not have debugging features. So it is hard to say what is the error source.
I have defined in header file:
typedef struct cm_packet {
CM_Header Header; //header of packet 3 bytes
uint8_t *Data; //packet data 64 bytes
CM_Footer Footer; //footer of packet 3 bytes
} CM_Packet;
typedef struct cm_inittypedef{
uint8_t DeviceId;
CM_Packet Packet;
} CM_InitTypeDef;
extern CM_InitTypeDef cmHandler;
void CM_Init(CM_InitTypeDef *handler);
CM_AppendResult CM_AppendData(CM_InitTypeDef *handler, uint8_t identifier
, uint8_t *data, uint8_t length);
And somewhere in implementation I have:
uint8_t bufferIndex = 0;
void CM_Init(CM_InitTypeDef *cm_initer) { //init a handler
cmHandler.DeviceId = cm_initer->DeviceId;
CM_Packet cmPacket;
cmPacket.Header.DeviceId = cm_initer->DeviceId;
cmPacket.Header.PacketStart = CM_START;
cmPacket.Footer.PacketEnd = CM_END;
//initialize data array
uint8_t emptyBuffer[CM_MAX_DATA_SIZE] = {0x00};
cmPacket.Data = emptyBuffer;
cm_initer->Packet = cmPacket;
}
CM_AppendResult CM_AppendData(CM_InitTypeDef *handler, uint8_t identifier
, uint8_t *data, uint8_t length){
//some check to see if new data does not make Data overflow
uint8_t i;
/*** ERROR HAPPENS HERE!!!! ***/
handler->Packet.Data[bufferIndex++] = identifier;
//now add the data itself
for(i = 0; i < length; i++) {
handler->Packet.Data[bufferIndex++] = data[i];
}
//reset indexer
if(bufferIndex > 64) {
PacketReady(); //mark packet as ready
bufferIndex = 0
};
//return result
}
The idea is to update the Packet.Data from some other source codes which have access to the handler. For example some other sources can call that Append function to change Packet.Data. But as you see in the code, I have commented the place which causes the micro-controller to go in hard fault mode. I am not sure what is happening here. All I know is exactly at that line micro goes into hard fault mode and never recovers!
This might be a race condition but before anything else I want to know I have written correct c !!! code then I try to rule out other problems.
In function CM_Init, you are setting cmPacket.Data to point to a local array:
uint8_t emptyBuffer[CM_MAX_DATA_SIZE] = {0x00};
cmPacket.Data = emptyBuffer;
Accessing this memory address outside the scope of the function yields undefined behavior.
As #barak manos mentioned, the buffer supplied to Data is allocated on the stack.
When you get to CM_AppendData, you are writing over memory that is no longer dedicated to the buffer.
You may want to use malloc so that the buffer is allocated on the heap instead of on the stack. Just remember to call free so that you are not leaking memory.
If you can't use dynamic allocation, it's possible to dedicate some scratch memory for all the Data uses. It just needs to be static.
Hope that helps :)
this is a bit of a strange use case so searching for existing discussion is difficult. I'm programming for embedded systems (Microchip PIC24 using XC16 compiler) and am currently implementing a communication protocol identically across 3 separate UART channels (each UART will grab data from a master data table).
The way I started out writing the project was to have each UART handled by a separate module, with a lot of code duplication, along the lines of the following pseudocode:
UART1.c:
static unsigned char buffer[128];
static unsigned char pointer = 0;
static unsigned char packet_received = 0;
void interrupt UART1Receive (void) {
buffer[pointer++] = UART1RX_REG;
if (end of packet condition) packet_received = 1;
}
void processUART1(void) { // This is called regularly from main loop
if (packet_received) {
// Process packet
}
}
UART2.c:
static unsigned char buffer[128];
static unsigned char pointer = 0;
static unsigned char packet_received = 0;
void interrupt UART2Receive (void) {
buffer[pointer++] = UART2RX_REG;
if (end of packet condition) packet_received = 1;
}
void processUART2(void) { // This is called regularly from main loop
if (packet_received) {
// Process packet
}
}
While the above is neat and works well, in practice the communication protocol itself is quite complex, so having it duplicated three times (simply with changes to references to the UART registers) is increasing the opportunity for bugs to be introduced. Having a single function and passing pointers to it is not an option, since this will have too great an impact on speed. The code needs to be physically duplicated in memory for each UART.
I gave it a lot of thought and despite knowing the rules of never putting functions in a header file, decided to try a specific header file that included the duplicate code, with references as #defined values:
protocol.h:
// UART_RECEIVE_NAME and UART_RX_REG are just macros to be defined
// in calling file
void interrupt UART_RECEIVE_NAME (void) {
buffer[pointer++] = UART_RX_REG;
if (end of packet condition) packet_received = 1;
}
UART1.c:
static unsigned char buffer[128];
static unsigned char pointer = 0;
static unsigned char packet_received = 0;
#define UART_RECEIVE_NAME UART1Receive
#define UART_RX_REG UART1RX_REG
#include "protocol.h"
void processUART1(void) { // This is called regularly from main loop
if (packet_received) {
// Process packet
}
}
UART2.c:
static unsigned char buffer[128];
static unsigned char pointer = 0;
static unsigned char packet_received = 0;
#define UART_RECEIVE_NAME UART2Receive
#define UART_RX_REG UART2RX_REG
#include "protocol.h"
void processUART2(void) { // This is called regularly from main loop
if (packet_received) {
// Process packet
}
}
I was slightly surprised when the code compiled without any errors! It does seem to work though, and post compilation MPLAB X can even work out all of the symbol references so that every macro reference in UART1.c and UART2.c don't get identified as an unresolvable identifier. I did then realise I should probably rename the protocol.h file to protocol.c (and update the #includes accordingly), but that's not practically a big deal.
There is only one downside: the IDE has no idea what to do while stepping through code included from protocol.h while simulating or debugging. It just stays at the calling instruction while the code executes, so debugging will be a little more difficult.
So how hacky is this solution? Will the C gods smite me for even considering this? Are there any better alternatives that I've overlooked?
An alternative is to define a function macro that contains the body of code. Some token pasting operators can automatically generate the symbol names required. Multi-line macros can be generated by using \ at the end of all but the last line.
#define UART_RECEIVE(n) \
void interrupt UART##n##Receive (void) { \
buffer[pointer++] = UART##n##RX_REG; \
if (end of packet condition) packet_received = 1; \
}
UART_RECEIVE(1)
UART_RECEIVE(2)
Using macros for this purpose seems for mee to be a bad idea. Making debugging impossible is just one disadvantage. It also makes it difficult to understand, by hiding the real meaning of symbols. And interrupt routines should realy be kept independant and short, with common functions hidden in handler functions.
The first thing I would do is to define a common buffer struct for each UART. This makes it possible with simultanous communications. If each uart needs a separate handler function for the messages, it can be included as a function pointer. The syntax is a bit
complicated, but it results in efficient code.
typedef struct uart_buf uart_buf_t;
struct uart_buf {
uint8_t* buffer;
int16_t inptr;
bool packet_received;
void (*handler_func)(uart_buf_t*);
};
uart_buf_t uart_buf_1;
uart_buf_t uart_buf_2;
Then each interrupt handler will be like this:
void interrupt UART1Receive (void) {
handle_input(UART1RX_REG, &uart_buf_1);
}
void interrupt UART2Receive (void) {
handle_input(UART2RX_REG, &uart_buf_2);
}
And the common handler will be:
void handle_input(uint8_t in_char, *buff) {
buf->buffer[buf->inptr++] = in_char;
if (in_char=LF)
buf->packet_received = true;
buf->handler_func(buf);
}
}
And the message handler is:
void hadle_packet(uart_buf_t* buf) {
... code to handle message
buf->packet_received=0;
}
And the function pointers must be initialized:
void init() {
uart_buf_1.handler_func=handler1;
uart_buf_2.handler_func=handler1;
}
The resulting code is very flexible, and can be easily changed. Single-steping the code is no problem.
I have a problem when I receive data from the eeprom.
first I made the following code :
#include <avr/io.h>
#include <avr/eeprom.h>
char NAME[5] EEMEM = "a001";
char UNIT[2] EEMEM = "C";
uint16_t CYCLICITY EEMEM = 2000;
int main(void)
{
while(1)
{
//TODO:: Please write your application code
}
}
and from this I have extracted a .hex and .eep files. Then I wrote this files with avrdude. First I write this wrong because I put only the .hex file on eerpom:w and I destroy some bytes, this is not so important. After that I write using the correct command and I see part of the data like in the next print screen.
I am saving a number , a C and a001 . As you see in the first row there is ..C.a001. which are the 9 bytes I wrote.
now in another program! I try to do this:
char EEMEM NAME[5] ;
char EEMEM UNIT[2] ;
uint16_t EEMEM CYCLICITY;
void _vReadEEPROM(char *au8Name,char *au8Unit,uint16_t *u16Cyclicity)
{
eeprom_read_block((void *)&au8Name,(const void *)NAME,5);
eeprom_read_block((void *)&au8Unit,(const void *)UNIT,2);
*u16Cyclicity = eeprom_read_word(&CYCLICITY);
}
The parametres are in a global struct :
typedef struct
{
uint16_t u16Cyclicity;
uint16_t u16Value;
char pu8Name[5];
char pu8Unit[2];
}EEH_layout;
In the while of the main I sent on the "Broken UART"(I have another topic on that). Until this code the USART sent the good value and garbage..but when I put this the USART is not sending anything, and as I beleive this is cause because of a 0(null) reading from eeprom.
The CPU is working because I have a 1 sec timer that interupts to blink a led. THis is working, so the probelm is that I got 0 from EEPORM.
ALSO I AM NOT SURE I UDERSTAND HOW TO WRITE THE EEPROM BECAUSE EVERYWHERE ARE A LOT OF TUTORIALS ON EEPROM BUT NOWHERE IS TELLING HOW TO CONFIG EEPROM AND ONLY READ. I do not want to have this params in my code, I want them from eeprom that I will write alone!
EDIT: the uint16 parameter is ok, I manage to read it over UART and it is 2000; But the chars are not ok, it is null.
EDIT:
TEST OK, the problem was that the params of function was not use ok. I change the function with pau8Name[] instead of *pau8Name, because the pointer wAS bad initialized!!
Always be aware of pointers!
The problem was with the uninitialized pointer. See EDIT in post!