XMC4500 Embed in a propriatary PCB

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

cross mob
Not applicable
Dear all,

I've embed the XMC4500 in a proprietary PCB, it is now soldered in the board, i've tried to maintain the layout and schematic similar to relax kit. I've started the debug mode with Dave, and the program was loaded successfully, I have used the Debug board that is possible to separate from the main processor in the relax kit. However, the program is not working and in the debug mode, the program resumes immediately and the following error is showed:


please advise.

What could be the problem? I could not find help regarding XMC chips, do they require any boot loader procedure or so?
7 Replies
Not applicable
Did you use the SW J-Link debugger that comes with Relax kit, or you used some other debugger? If it was J-link, then confirm the memory addresses code was written to. It should have been written on 0x080000000 and onwards. That is the location of cached ROM.
Not applicable
Yes, I used the SW J-Link debugger that comes with Relax kit, I've separated it from the relax kit and used it in my board. The thing is that the same program when downloaded to the relax kit lite everything works great, but when I connect to my board it does not work like if it coudn't find the main.c.

My question is that if using XMC chips off the shelf it requires any kind of configuration. Not sure about how to "confirm the memory addresses code was written to. It should have been written on 0x080000000 and onwards. That is the location of cached ROM. "

thanks in advance
Not applicable
When I pause the DEBUG it shows this:


which is completely different from what is showed using the relax kit
Not applicable
It does not require any kind of configuration off shelf. It works as shipped.

From last figure, it appears that your program is not being loaded into your Flash ROM. These addresses should have been in the order of 0x80000000 or 0xC0000000. Open linker_script.ld and find MEMORY tag. Confirm these addresses for Cached and uncached ROM. This file would be in main project directory. Tell me what are the addresses. We'll debug it further afterwards.
Not applicable
If you can give me a screen shot of console after flashing your code in the controller, that would be a great starting point for debugging............................
Not applicable

thanks for your reply.

Here is the memory tag in my linker script file:

FLASH_1_cached(RX) : ORIGIN = 0x08000000, LENGTH = 0x100000
FLASH_1_uncached(RX) : ORIGIN = 0x0C000000, LENGTH = 0x100000
PSRAM_1(!RX) : ORIGIN = 0x10000000, LENGTH = 0x10000
DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x10000
DSRAM_2_comm(!RX) : ORIGIN = 0x30000000, LENGTH = 0x8000

stack_size = 2048;

Regarding the console, in Dave:


I've tried to download the .bin file through Jlink downloader, here is the Console image:


I says "CPU is not halted", but doing the same process for a normal relax kit, it works perfectly.

Some time in this process it says that "Flash programing was not necessary" but this time everything appears to work fine less the last part.

please help
Not applicable
Well there is the error. Your debugger is unable to halt CPU and hence it is unable to write anything in Flash. As you mentioned that it worked previously with relax kit, I think the reason for proper functioning might be that an older flashed program would have been running on your system. Let me share my console. It clearly states which memory addresses have been written and what is the value of PC.

Possible Problems:

1. The most probable reason here can be frequency mismatch. Relax kit has a 12.0 MHz crystal oscillator and this is default value of frequency. What oscillator you used in your PCB?
2. A less probable reason for this error might be ROM corruption. Although there are very little chances of corrupted ROM but this can be the case.
3. Finally, you can look for your debug configurations. I have following configurations. See if there is any difference. You can try using Auto speed mode. It's been highlighted in the screenshot.


I think frequency matching would solve the problem.

Saqib Ahmed