Close

Infineon - scary movie, part one.

A project log for MCU how-tos, reviews, rants

As title says, my random essays about microcontrollers, all in one package

jaromirsukubajaromir.sukuba 11/22/2017 at 08:311 Comment

Offering from Infineon piqued my interest lately, as the price for Cortex M0 with 32k FLASH and 16k RAM in small package for under 1EUR from EU stores isn't bad. I bought one XMC1301T016F0032ABXUMA1 (oh my) and tiny devboard XMC2Go and Infineon is kind enough to provide some design resources. +1 point from me.
They also provide IDE named DAVE based on Eclipse and GCC, though being only offered for Windows. Meh, I don't mind it much, as I'm going to switch to native Linux tools as soon as possible, vendor IDE is usually good enough to get basic grasp and move on to something useful later. But anyway, I would be happier if they provided also non-windows variant of the tool. It's late 2017, dominance of "Wintel" is not as strong as used to be.

So, IDE installed, let's run it and create new project. Nope.

Clicking to Next, but nothing happens. It just froze here. So again, Cancel, new project, Next... Next, Next, Next, Next, Next, Next, NEXT NEEEEXT... Screw you. Closing IDE, trying the same... no avail. No error messages, just non-responsive program. Restarting windows (because that's what always helps), then running IDE, the same result. I just can't start a project on freshly installed IDE.

Googling time... it reveals I'm not the only one with this issue. So, after I install the complete dedicated IDE from Infineon solely for Infineon MCUs, I need to install some more libraries for this dedicated Infineon IDE to actually support the Infineon MCUs. Go figure.

Since I don't want to spend any more time restarting everything and figuring out what everything is needed, I just install everything available. After one or two restarts of the IDE and half an hour spent dicking around I'm finally able to start a empty project. Hallelujah, I thought - at the time I didn't know the worst is still to come.

Hey Infineon, why on Earth the IDE dedicated to Infineon MCUs isn't able handling of Infineon MCUs? Why the plugins or whatever can't be installed from main install?

With the XMC2Go kit in USB port (being enumerated as J-Link debugger) I built the empty project and flashed the FLASH of target MCU on kit, everything went smoothly, so I considered this as done. But devkits are always just training wheels and you don't own the MCU unless you can buy virgin part, stick it to PCB and blink a LED with it. I took out my XMC1301T016F0032ABXUMA1 (once you start diving into ARM world you notice the weird part numbers), soldered it onto one of my breakout boards and tested it for continuity and shorts. 

For flashing the board, I elected for J-link EDU I had on hand, just to connect it. Pins 5 and 6 are GND/Vss, now I need SWD pins. And they are not listed in datasheet. Hey Infineon, you always list such as important pins in datasheet, no matter what. Datasheet is go-to resource, the first document one takes look at. I opened reference manual, being mere 1337 words long (oh 1337!) and sine nobody in his/her right mind would start reading it page by page I hit SWDCLK into full-text search. Notice how easy and fast I progressed here, since I knew what to search for, beginner would spend hours looking for what to look for.

I found the SWD pins are shared with other pins

depending on boot mode, but SWD are top ones, so probably are the default for given pins, what would be logical choice, as every other manufacturer has programming/debugging pins enabled by default. Isn't it logical? Yes it is. Is this the case of Infineon MCUs? No, it isn't. So I connected SWDCLK pin of J-link EDU to P0.15 and SWDIO to P0.14, asked J-link software (DAVE was off at the time) to find the target on SWD interface and... it didn't found anything (<insert Spaceballs reference here>). Never mind, check connections, try again, reboot, reinstall drivers, reinstall software, try in DAVE, install Keil uVision, reboot few more times, take out SMT32 Discovery, google, install J-link firmware on it, try it in DAVE, Keil, J-link, reinstall drivers, reboot a few times, google, resolder new chip, revert Discovery back to St-link, try from Keil, revert to J-link, try a few more times, try from openocd with both ST-link and J-link firmware, try and repeat ad nausea. The damned chip just will not respond on SWD pins. I thought the firmware on XMC2Go board is somehow special, so I extracted the target MCU from it and soldered wires from points where original MCU was connected to debugger chip.

I will not tease you any longer, it didn't work neither.

After a bit of googling and searching in reference manual I found out the SWD pins aren't default pins after boot on virgin MCU. There is resident bootloader shared with SWD pins with half a dozen on possible modes of operation, depending on value of single word in FLASH memory, called BMI (<insert BMI versus heavy bones reference here>). So basically, in order to use SWD to program FLASH, you must first program FLASH (Joseph Heller, is that you?). J-link nor any other programmer/debugger doesn't know anything about serial bootloader and obviously can't handle it. There is no clear hint in DAVE you have to do so or how to do it. Again, googling brought me to user forum where somebody hit the same problem.

It was clear from that point, kind of. The DAVE has really application, called "BMI set and get" to handle the serial bootloader, but it just didn't work. Click "Get BMI" and nothing happens. No error, no status line in the window, absolutely nothing, Seems like Infineon has some affinity dialog windows don't respond.

Then I googled further and found out there is another software, not related to DAVE, able to do the same for me - what I need to to change the single word in FLASH. Ok, so I downloaded Infineon Memtool, installed, connected everything and hit connect... being not very surprised it didn't work. 

I goofed around settings a bit

here and there

to find out the random settings are working, oh my!

Clicked Device->Boot mode and dialog window asked me what boot mode I want to choose

It is important to not make any mistake here, as you can make your precious MCU OTP. I selected proper mode

hit Set and... Memtool lost connection. Oh I didn't mention that if you select different BMI, the previous means of communication is lost, so you have to connect vie the newly selected interface. There is no backup in case you make a mistake. Fingers crossed, start DAVE, hit debug button... and it worked! Now I'm able to debug and program the MCU from DAVE.

Here is obligatory blink-a-led

In nutshell, the work with this MCU was hard, because:

1, There is not clear indication in datasheet where are SWD pins, how are shared and what is the default mode. Yes, you can find it in RM, if you know what you are searching for, but this needs to be more obvious.

2, Honestly I have no idea what is the advantage of bootloader pins switching with no fallback mode compared to just SWD, as rest of world is doing.

3, The thing in point 2 isn't clearly stated in DS, again. User forum isn't replacement for documentation.

4, Feature of editing the thing in point 2 isn't working in IDE. Once it can't connect it throws some generic garbage error dialog instead of reminding you the bootloader.

5, The IDE can't work out of the box.

I wrote this project log as reference for the future in case anyone else is struggling to make it work. Now when windows tools are working, I'll try to build/load the project using FOSS tools too.

Discussions

[deleted]

[this comment has been deleted]

jaromir.sukuba wrote 11/22/2017 at 12:26 point

For Cortex M vendors - ST, NXP, Microchip or perhaps some parts from TI do have advantage of having wider user base among hobby users, so one is more likely to find somebody struggling the same, along with solution to the problem. The silicon vendors are all about the same, with less than optimal documentation, no support unless purchasing 1E6 units, buggy devtools, sometimes weird peripherals, silicon bugs, you name it. But for major players the idiosyncrasies are known and you know them before hitting them hard. Something like "go with the flow" attitude - but I still love to discover the less known MCUs, it helps to keep wider view.

Being Infineon parts known better along "general public", I wouldn't spend a day trying to get the damned SWD working, as I would immediately know that I need to reconfigure BMI. The chips itself aren't that bad, but I wouldn't use them in my next project, probably. I don't know how many gremlins are still hidden somewhere.

  Are you sure? yes | no