2020-12-11 09:58 AM
Hi,
I suddenly get this kind of interrupt in a code that was previously working perfectly. The instruction that makes this interrupt arise is *dst=*ptr. You can check below the function:
void readHistoryFile(unsigned short * dst){
unsigned short * ptr = HF_P_ADDR; //Pointer to Flash position (starts at 0x0807F800)
for(int i=0; i<N_HF_EL;i++){
*dst = *ptr;
ptr++; //Increment Flash pointer by 2 bytes
dst++; //Increment destination pointer
}
}
The initial dst address is 0x2001ff30.
I can copy some Bytes but, whenever I try to write into the address 0x2001ff50, I get the said interrupt. Also, have in mind that this problem showed up suddenly, without any change to the firmware.
Is there any good way to debug this mysterious behavior?
Thanks in advance
Solved! Go to Solution.
2020-12-12 04:03 AM
PROBLEM SOLVED
I never actually got to understand what happened. I also couldn't write to the flash address.
Erasing the entire page solved the issue and now I can easily read and write to the flash memory. I guess somewhere in time a writing operation was not successfully done, maybe corrupt data, thus the issue.
Any thoughts on that?
2020-12-11 10:13 AM
Do did not say anything about the size of N_HF_EL. I expect you overwrite something, e.g. stack.
2020-12-11 10:22 AM
I'm not familiar with the STM32G747VE, but generally the NMI would be indicative of an ECC, Parity Error or Clock Security.
If for example a portion of an Flash lines was unwritten, or a RAM based error.
2020-12-11 02:03 PM
> If for example a portion of an Flash lines was unwritten,
... or written twice.
(Not going to look it up now, but shouldn't reading unwritten FLASH throw only a single error?)
JW
2020-12-12 01:58 AM
Your MCU G747 dont exist , realy 474 dont have memory , that you try write, only mapped CC.
Embedded SRAM STM32G474xB/xC/xE devices feature 128 Kbytes of embedded SRAM. This SRAM is split into three blocks:
• 80 Kbytes mapped at address 0x2000 0000 (SRAM1). The CM4 can access the SRAM1 through the System Bus (or through the I-Code/D-Code buses when boot from SRAM1 is selected or when physical remap is selected by SYSCFG_MEMRMP register). The first 32 Kbyte of SRAM1 support hardware parity check.
• 16 Kbytes mapped at address 0x2001 4000 (SRAM2). The CM4 can access the SRAM2 through the System bus. SRAM2 can be retained in standby modes.
• 32 Kbytes mapped at address 0x1000 0000 (CCM SRAM). It is accessed by the CPU through I-Code/D-Code bus for maximum performance. It is also aliased at 0x2001 8000 address to be accessed by all masters (CPU, DMA1, DMA2) through SBUS contiguously to SRAM1 and SRAM2. The CCM SRAM supports hardware parity check and can be write-protected with 1 Kbyte granularity.
2020-12-12 02:49 AM
I don't think so. N_HF_EL = 16
The problem occurs when trying to copy 2 Bytes from address 0x807F008 to 0x2001FF50
2020-12-12 02:52 AM
The address in the flash is written (0x63 and 0x34).
So, happening in a simple instruction that copies 2 Bytes could that mean that I am dealing with corrupt memory?
I've tried with memcpy() function and the problem persists!
2020-12-12 04:03 AM
PROBLEM SOLVED
I never actually got to understand what happened. I also couldn't write to the flash address.
Erasing the entire page solved the issue and now I can easily read and write to the flash memory. I guess somewhere in time a writing operation was not successfully done, maybe corrupt data, thus the issue.
Any thoughts on that?
2020-12-23 09:49 AM
Edit thread subject and write correct STM32 ...