Flash Memory - Sector0 - Now unable to connect via debugger/mini-wiggler

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Hello

Currently working on a project which requires storing some analogue calibration values to flash memory.

Working using the FLASH_002 app.

Trying to understand/confirm how the flash memory is allocated/structured by default. In my code I have written the following array uint32_t CalData[11] to BASE_SECTOR0, since doing this upon power cycle I have been unable to connect to the XMC4500F100F1024 with either the J-Link debugger or a mini wiggler.

Does anyone know the default start of code memory? Assume this is defined somewhere within my DAVE project?

Does anyone know if there is anything at the base address of Sector0 which being over written will cause these issues?

Any thoughts how I might be able to erase all flash memory in attempt to recover from this situation?

Any suggestions or ideas would be greatly appreciated 🙂

Thanks


Dave
0 Likes
5 Replies
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
Hi DAVE,

Does anyone know the default start of code memory? Assume this is defined somewhere within my DAVE project?
See attachment below. Generally code execution starts from 0x08200 0000 onwards.

Does anyone know if there is anything at the base address of Sector0 which being over written will cause these issues?
As mentioned above that the startup code runs from address 0x08200 0000.

Any thoughts how I might be able to erase all flash memory in attempt to recover from this situation?
I think your code in sector 0 cause the MCU to enter into a TRAP mode after reset hence it is not able to interface with the debugger. I am not sure if the debugger has a way to halt after RESET and followed by doing an erase to the flash.


1373.attach
0 Likes
User8819
Level 4
Level 4
Use program j-flash from segger and choose option erase chip. Try several times if erasing fails.
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
After RESET the debugger will halt the CPU from executing further.

1376.attach
0 Likes
Not applicable
Brilliant!

Thanks for the help.

Dave
0 Likes
Not applicable
Travis

Thanks again for your help on this - got a few more questions around the Flash memory on the XMC4500

Struggling to understand from the documentation/reference manual the difference between Cached and UnCached memory? In which of these is my code by default stored and operated from?

From the DAVE generated MAP file how can I determine the programme size and thus work out the best place to store some variables?

I am using the FLASH_002 app to attempt to read and write from/to the Flash memory on an XMC4500. Given they are constants which are being stored they need to be at fixed addresses, I need to understand fully how the flash memory is managed by DAVE to ensure I do not cause unwanted issues to my project.

Cheers
0 Likes