Robots are revolutionizing our lives in many ways. Join our webinar to learn about Infineon’s broad portfolio of robot building blocks.
Click here to register.

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

XMC™ Forum Discussions

Level 2
Level 2
5 replies posted 10 sign-ins 5 sign-ins

Hello all.

I developed my application on a XMC1400 Boot Kit, and finally took the big step to actually design / build my board with a XMC1404 on there. To keep things very much the same as the Boot Kit configuration, I replicated the configuration by which the Boot Kit flash-loads (and debugs) the XMC via pins 0.14 (SWD) and 0.15 (CLK). I snapped off the programmer board from the Boot Kit, and hooked those two pin to the XMC on my board via (shielded) wires.

I powered up the board and when I try to flash my program via the regular way in DAVE but .... It does not work. J-Link GDB Server failed .. Segger message is that "Could not connect to target". 

I can see the signals on the oscilloscope as the programmer board and they even look similar to what I see on pins 0.14 and 0.15 on the Boot Kit. 

Now there could be several things still wrong, but I'm basically asking if I may have done something simple wrong :

- Is the XMC supposed to be able to be flashed via those two pins only ? Or do I need to keep other pins high or low when DAVE/JSegger loads my application onto the XMC ?

- Is the crystal oscillator supposed to run when you power up the chip ? I see that the (20 MHz) oscillator on the Boot Kit does NOT run, so does it use an internal clock to run if the external clock is not present ?

- Any other suggestions on how to debug a first swap from a XMC Boot Kit to an actual board ?

Thanks !

2 Replies
Level 2
Level 2
5 replies posted 10 sign-ins 5 sign-ins

Let me add that the XMC on my own custom board is new and never been programmed.

Is such a device different from the XMC that's on the Boot Kit board ?

Level 2
Level 2
5 replies posted 10 sign-ins 5 sign-ins


I am new to micro controller programming, and since I did not find simple and clear documentation on how to do this, I spend some time on this issue, and I would like to share my findings, hoping that it's useful for other beginners with an XMC MCU.

I used an XMC 1400, both on the Boot Kit development board (which includes a little programmer board), and my prototype custom board that actually runs my application. The two chips did not behave the same, as described in the post above. I wanted to know why that was, and if I can still develop and debug the XMC on my own board, just like I did on the Boot Kit.

It turns out that the issue is rather trivial :

The chip on a Boot Kit comes pre-programmed with what is called "User mode with debug enabled (UMD)" in the reference manual (BMI code "0xF8C3" ), while any new chip you buy (and mount on your own board) is pre-programmed in  "ASC Bootstrap Loader mode (ASC_BSL)" mode (BMI code "0xFFC0" ). So, to let them behave the same, all you need to do is set the BMI code of your new chip to BMI code "0xF8C3" and it behaves the same as the one on your XMC evaluation Boot Kit. 

To do that for a new chip, you need to get a boot loader program working, and there is application note AP32277 here with accompanied source code for the boot loader 'XMC1x_ASCLoader' and the application program 'XMC1x_Boot' to get you going with that. If you do this all right, you can debug and develop (with DAVE/Eclipse/any other IDE) just like you did on the chip on the evaluation board.

However, in practice, this is not so simple, and if (like me) you have not done this before, you (as I did) can seriously get lost on which state your chip is in and why some things are not working as advertised. So here are some notes of advice if you do this for the first time :

1) First try to swap the chip on your Boot Kit from 'UMD' to 'ASC_BSL' mode. That gives you some experience with the process on a board that you know is functioning.

To swap the XMC from 'UMD' mode to 'ASC_BSL' mode, application note AP32277 suggests to use "BMI Set Tool". If you have that tool, great, use it. I could not find it on my DAVE distribution, but I found a much easier way : Just use the XMC API routine to change the BMI register : 


Once you call  XMC_SCU_SetBMI (0xFFC0) your chip will switch to ASC bootstrap mode, and reset itself.  It will be waiting for UART access via either port 0.14/0.15 or port 1.3/1.2, for you to start the Boot loading process via UART, using the 'XMC1x_Boot' / 'XMC1x_ASCLoader' combination from the app.

Be careful NOT to program "production mode" (0xF8C1) or even ASC with timeout (0xFFD0) since you will have a hard time getting the chip to listen to your ASC calls with XMC1x_ASCLoader.exe, and then you cannot change your chip's program any more.

In fact, in my application I'm programming a state where I can change the BMI of the chip, just so that I always have a path into accessing my device and changing its program. Even after it is in production mode.

2) Boot loading with the Windows XMC1x_ASCLoader.exe application is tedious : For example, even if you use this application just to swap your BMI mode from the default ASC_BSL mode to SWD/Debug mode, you still need to upload (the app calls it 'download') a hex application file, or else it won't get to the point where you can change your BMI mode. Also, it's a windows application, and your com port may vary and may change after each power-reset of the programmer. And on top of that, if you want to stay in ASC_BSL mode, then the XMC1x_Boot/XMC1x_ASCLoader.exe combination will not reset the chip after you upload your application, so the chip will never actually run the application program that you just uploaded. It only runs it if the BMI mode changes (to debug mode). Which is highly annoying and confusing. 

I don't have a Windows compiler, so I can't change theXMC1x_ASCLoader.exe to fix the above issues, but since I do most of my work on MacOS or Linux and this board should communicate with a Linux based Single Board Computer any way, and C/C++ is my field, I will port the "XMC1x_ASCLoader" to standard C/C++ so that I can boot load my XMC from a Raspberry Pi or even via a USB from a Mac laptop. 

If you are interested in this port, let me know and I can publish the code here (Infineon copyrights still in there, since this is clearly 'derived' code).

3) One final note once you go to program the chip on your board : The programmer board on the Boot Kit has TWO separate ports on its (8 pin) debug header : port 1.3/1.2 fixed as ASC / UART access, and 0.14/0.15 fixed  for Debug/SWD / UMD access. So if you want to use this programmer for a custom board that has only ONE UART port, you need to turn your wire around in the 8-pin header between boot loading and debugging. Also, you need to let your boot loader listen to that single port that you use (check the source code for 'XMC1x_Boot'). And if you want to go back to debug mode, make sure your debug port is set correctly in BMI mode : 0xF8C3 for debug via port 0.14/0.15 and 0xFAC3 for debug via port 1.3/1.2. 

I fell in most of these (and many other) traps when moving my project from a Boot Kit/Relax Kit to an actual application board, so I hope that these notes will help other beginners to see that at the core the issue is not complex. There are just many small steps that all matter, and that are not clearly documented. But once you went through them, you can develop, debug and run your application on your own board, and you will be grateful you went through the details of exactly how your own machine works.

Happy coding !

This widget could not be displayed.