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 :
XMC_SCU_GetBMI() and XMC_SCU_SetBMI()
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 !
