cancel
Showing results for 
Search instead for 
Did you mean: 

I am using EEPROM_Emulation to write flash and used as eeprom, It works fine . I can read and write but porblem is i can write(or update) it 3 times 4th time it hangs and i can't write it . what can be problem.

embo
Associate II
 
9 REPLIES 9
Bob S
Principal

Can't even guess without more information. What have you tried to debug this? You have the source code, so have you used your debugger to trace through the code to see where it hangs? Or paused the program when it is hung and see where the you are? Are you using an RTOS? What CPU are you using? How many pages of FLASH have you allocated to the EEPROM emulation? How much data are you trying to store?

embo
Associate II

uint16_t VirtAddVarTab[NB_OF_VAR]  = {0x5555, 0x6666, 0x7777};

.....................{

EE_WriteVariable(VirtAddVarTab2[1]+index, temp);

}

yes I am using RTOS

Every time i write it takes more and more time but after 4th time it hangs

I am using stm32f769i eval board , I am just write a string but writing at the run time..

Bob S
Principal

It appears this EE_WriteVariable() call is in a loop of some kind (I'm guessing because of the "+index")? Is that the case? Seeing more of your code might help here.

And in the L4xx version the EE_WriteVariable() function is static (i.e. not public) and not meant to be called directly from user code. Though on the other hand, EE_WriteVariable32Bit() simply calls EE_WriteVariable(), so I guess no harm there.

Going back to my original response - what have you done to try and debug this? Are you looking that the status returned from any of the EEPROM functions (doesn't look like it from your code snippet above)? Have you used the debugger to step into the EE_WriteVariable() function to see where it hangs? Have you let the program run, then when it hangs, pause execution and see where you are?

If the EEPROM area is in the same FLASH bank as the code you are running (I don't know if the F769 has multiple banks of FLASH), your code will pause during FLASH write and erase operations. That means no interrupts serviced (they will still be pending, and will be serviced when the FLASH operation is complete). Could you be missing an interrupt that is causing some other part of your code to hang?

embo
Associate II

for (int index = 0; index <= ((length 2); index++) {

uint32_t string*((uint16_t *) strdata+index); 

EE_WriteVariable(VirtAddVarTab[1]+index, string)

what I just observe is , If i have short string i can write iz more times and if it is long , I can write lesser times and it hangs .. I will write you after debug as you suggest.

embo
Associate II

okay it went to HardFault_Handler() after third time

Bob S
Principal

So in your hard fault handler, look at the fault registers to see why you got there. @Community member​ has posted sample code for reading the registers and displaying their content. One example (after much frustrating search attempts in this #$#$^ forum) is here:

https://community.st.com/s/question/0D50X0000Az475VSQQ/why-does-my-stm32h743vi-processor-throw-a-hard-fault-exception-when-i-place-my-hal-usarto-variables-in-sram1sram2-or-sram3-but-it-runs-perfectly-when-the-variables-are-placed-in-axi-ram

FYI, each call to EE_WriteVariable() will write 8 bytes to FLASH. By the looks of your small code sample above (which is not valid code, by the way), you are storing 2 bytes from the string on each call. How long are your strings? And you never answered my questions about how much space (how many FLASH pages) you allocated for the EEPROM emulation area. Did you go through the calculations in the app note to figure size based on number and size of data that you want to store? Did you EXCLUDE that space from the linker map so that your program cannot occupy that same space in FLASH? Or at least look at your MAP file and verify that your program doesn't overlap EEPROM pages?

I know this is late, but it may help someone else: you are misusing the library. with the current library, you can only save up to an unsigned short in each location in your case: {0x5555, 0x6666, 0x7777}. the above code will not work correctly because when the bank is full, it won't transfer the data to the other bank, plus it may cause other issues. here is my modification code that will work with any data size.