INFINEON XMC1100

[jannek]

Hello Fellows,

I didn't find a thread for this great MCU.
Features:
- Cortex M0
- 5V operating voltage 
- up to 64kbytes of flash
- 16kbytes of RAM
- 8kbytes of ROM routines etc.
- 12bit ADC
- 2x serial comm peripherals (all in one beasts)
- 4x 16bit flexible timer slices (beast clearly made for power control applications such as inverters)
- Comprehensive event system
- Holistic approach API XMCLib. I think it's the best I have yet used with the least amount of need to touch registers directly for any reason.
- DAVE4 IDE with "APPs" or code generators to say. Helps a lot to get somewhere with complex peripherals.
- XMC 2GO development board for low low price of 6usd(includes jlink lite on board).
- Low cost (if you are able to get chips with smaller flash you can get to around magical threshold of 1usd) 

I hope to know if anyone here has fiddled with this micro?
I got pass the timer and serial comms but..
I hit the wall with ADC not converting in the most trivial single-shot + single channel + software load event situation and peripheral is pretty complex just to try things randomly. Anyone here have working example of ADC code? I'd appreciate any code example that actually performs any conversions.

regards,
JK

[JPortici]

I didn't find a thread for this great MCU.

dsPIC33EV any day for me

good luck

[technix]

I have that XMC2Go board, but I did not manage to get it up and running at all with my fully open source tool set.

[legacy]

I guess it's like the Infineon XMC4500. Evaluation boards (e.g. "Relax XMC4500 kit" (1)) are supported for rapid application developments like DAVE and the support for other ecosystems is very poor or very expensive

e.g. Keil has support for the XMC4500, but you have to purchase the full license.

(1) I have one for sale because I am no more interested in this chip.
25E + S/H

[tszaboo]

Well, after the XC167 and other 16 bitters from infineon, I can safely say that I'm not touching any microcontroller that company will ever make.

[legacy]

including the Tricores 

[jannek]

I have not been in the game so long I would know. I just think it's not so bad(man.. even I got around it pretty easily) and I have used worse chips in any sense(dodgy stuff, bad API, workarounds to do basic things).
I think in XMC1100 infineon tries to make something more approacable for wider userbase.
If I get ADC converting and infineon keeps chip available with consistent pricing the chip will become one of my favourites for sure.

I have that XMC2Go board, but I did not manage to get it up and running at all with my fully open source tool set.

http://eleceng.dit.ie/frank/arm/BareMetalXMC2Go/index.html


And hey..  I have still samples to get from ADC.. Anyone?

[technix]

I have that XMC2Go board, but I did not manage to get it up and running at all with my fully open source tool set.

http://eleceng.dit.ie/frank/arm/BareMetalXMC2Go/index.html

Hmm... That does not seem like the kind of code I am used to. Maybe I am spoiled by the simplicity of STM32...?

[chickenHeadKnob]

There are only two reasons I can find to be attracted to the infineon XMC 4xxx line. Namely two types of peripheral: a high resolution pwm timer and ethercat. Otherwise they seem unexceptional.

[fitzgerald]

Have a look at the "VADC_MEASUREMENT" example provided with XMCLib. It is available for XMC1200 and XMC1300 but should be straightforward to get it working on XMC1100.

Personally I like the XMC series. They have a bit of a steep learning curve, but the peripherals are very flexible and powerful.

[jannek]

I have that XMC2Go board, but I did not manage to get it up and running at all with my fully open source tool set.

http://eleceng.dit.ie/frank/arm/BareMetalXMC2Go/index.html

Hmm... That does not seem like the kind of code I am used to. Maybe I am spoiled by the simplicity of STM32...?

I tried to use XMC1100 with OpenOCD. First of all it was a task to get OpenOCD plugin installed to DAVE. Ended up instead of trying to install newest possible to find plugin with matching version number to gnuarmeclipse core and jlink debugging already installed.

This is the repo to add to DAVE that includes openocd plugin version 4.1.4.201704251808 (at least for now)
http://dl.bintray.com/gnu-mcu-eclipse/updates/

Before debugging on blank xmc1100 I used Infineon Memtool and usb-uart adapter to change it's BMI to Debug mode.
NOTE: XMC 2GO comes with BMI: SWD0 preprogrammed.

OpenOCD GDB server complained about target not halted.
Added to configuration to gdb-attach to perform halt and got session running.
But all I get is execution stuck to some handler in startup code. Meh. I was done with it. I'm not here to fight the debugger. Not this time.

I blew with hot air XMC1100 and series resistors off from XMC 2GO. Soldered a small prototyping board to top of it using pin rows. Pulled SWDIO and SWCLK lines from serial resistor footpads to that prototyping board and added 820ohm / 1500ohm(debugger side pulldown) resistor divider to both lines. Connected to my 5V operating voltage XMC1100 target board and got instantly hello world running with real jlink debugging without touching any configuration at all  It has worked without any glitch for a week or so now full days of debugging. Flawless victory!

Planning to get this. 1kVDC isolation. You would never believe the price of it. If I'm lucky it's not even vendor locked(in jlink debugger) but.. will see when I decide to get one.
https://www.infineon.com/cms/en/product/evaluation-boards/kit_xmc_link_segger_v1/


THEN A CONCLUSION TO ADC ISSUE

Have a look at the "VADC_MEASUREMENT" example provided with XMCLib. It is available for XMC1200 and XMC1300 but should be straightforward to get it working on XMC1100.

Personally I like the XMC series. They have a bit of a steep learning curve, but the peripherals are very flexible and powerful.

You would think that it's a straight forward process in many such cases.
But XMC1100 ADC lacks most of the facilities VADC_MEASUREMENT requires.
It just doesn't mix with XMC1100 

Here is a working example for simple ADC operation that is also 2018 fresh. Done by Infineon so no funky stuff. Utilizes XMCLib efficiently too.
>>> https://github.com/Infineon/XMC-for-Arduino/blob/master/arm/cores/wiring_analog.c  <<<

12bit ADC conversions on Cortex M0 platform that is running from 5V line. How often you get that?

In this case I needed to port codebase from 3.3V Cortex M0 platform with 10bit ADC that I eventually pushed all way to 2.6V operating voltage to get more resolution to relevant 5V/2 sensor output signal range while the sensor was operated from 5volt rail. You can imagine operating both from single voltage line is a bit more pleasant and I could threw away dozens of components from the design making it significantly smaller, simplier and cheaper.

Next maybe I need to make some flash writes and reads for calibration. Maybe some BMI(boot mode) changes to be performed by program itself for production. Will see.

I'll keep you posted if I find something else amusing.

[jaromir]

Oh Infineon, I wrote some notes in case I'll ever return to them again https://hackaday.io/project/27250-mcu-how-tos-reviews-rants/log/70767-infineon-scary-movie-part-one
Just blinking a LED with their MCUs was funny at times. I can't say I want to experience any more of their sense of humor.

[jannek]

Oh Infineon, I wrote some notes in case I'll ever return to them again https://hackaday.io/project/27250-mcu-how-tos-reviews-rants/log/70767-infineon-scary-movie-part-one
Just blinking a LED with their MCUs was funny at times. I can't say I want to experience any more of their sense of humor.

They have fixed the IDE apparently. There was no separate downloads but one really heavy zip inside another zip. I think extraction crashed a few times. It was a bit meh to have no installer, but it's not about formalities after all. Maybe in some situations having installer would be even concidered harmful as employees do not have elevated execution rights on their workstations and need to fight tech guys to get softwares installed. Jeez. But in comparison to other vendors IDEs everything works how it's expected to work.

Rant about BMI is just useless.  Read the XMC 2GO pdf about it's BMI configuration and reference manual of XMC1100 about BMI and some pdf about Infineon MemTool and that's it. Effort to figure it out is nothing if you are really working on something. Good thing about it is that it listens both serial channels when blank chip is in it's default BMI mode without any tricks performed. Just use whichever fits the overall design. And then you can use the same pins for debugging if you wish. Man, you can go even with single pin all the way if your really need to.

This explains BMI further:
>>> https://www.infineon.com/dgdl/Infineon-ApplicationNote_XMC1000_Microcontroller_BootModeHandling-AN-v01_00-EN.pdf?fileId=5546d462525dbac40152d0591da87d34 <<<

It also mentions rom function to call in order to change BMI. If you have SWD - you have platform that you can make call that rom function(needs master reset after that in order to stick). Making mistake with BMI equals to having made mistake on any other chip and locking it for good, but sure it's a bit easier to make with this one as you basically need to fiddle with BMI.

Interesting detail: This chip has no reset pin that amused me a while. The pins are all about business that must be the philosophy behind BMI too.
Another interesting detail: There is pins without output drivers. Heads up.

At current day all the resources needed seem to be there. That ADC thing(Valig Flag was not been set in ADC result register) needed some lucky googling though when a bug or code I used for testing ADC caused ADC results to be 10bit instead of 12bit and I googled "xmc1100 adc resolution" and I found the newer 2018 code.

Community support is quite poor, but ultimatelly there is only one person that solves problem at the hand.

[jaromir]

Rant about BMI is just useless.  Read the XMC 2GO pdf about it's BMI configuration and reference manual of XMC1100 about BMI and some pdf...

I wouldn't call it useless. A few people thanked for it and discussed it with me via personal messages, being burned by the same gotcha. Yes, it's all in documentation and it's easy to find it once you know what to look for. But you don't know if you don't know, because you don't know. I found it too, after I spent a few hours dicking around SWD connections and tools setup.

Documentation should be not only factually correct and complete, but also helpful, as it's intended for humans.

[jannek]

Still nothing found to be intimidated for

I thought I Jinxed myself with all the Fuss about BMI.
I needed to change from Debug (HAR - Halt After Reset) to Debug to get the thing to run standalone.
Note to self: Don't use HAR unless your application requires it

I did BMI change like this (reconstruction)

Code: [Select]

#include <xmc_common.h>
#include <XMC1000_RomFunctionTable.h>

...

#define BMI_DEBUG_SWD0    0xF8C3
#define BMI_DEBUG_SWD1    0xFAC3

uint16_t write_bmi = 0;    //Do not initialize write_bmi with anything but 0

//Program conditions to set write_bmi?

if(write_bmi){    //Set breakpoint here and set write_bmi if you want to program new BMI
    //Place delay here to catch cathastropic flash-cycling in time.
    _BmiInstallationReq(BMI_DEBUG_SWD0);
    SCU_RESET->RSTCON = SCU_RESET_RSTCON_MRSTEN_Msk;    //Master Reset
}
So.. It's really that simple

Target started running the program without halt. Tried to launch debugger and it did. Nice 
Took the target off from debugger probe for some testing and when I placed it back. Debugging didn't work anymore and first thing I thought I jinxed myself now.. BMI didn't stick and worst case it's now locked? Tried Infineon memtool with serial protocol and nothing. Quickly replace the chip. Memtool(using initial serial mode) says Okay and I set BMI to SWD0. Same thing - couldn't connect to target.

So:
- BMI value has been tripple checked before against reference manual and appnote. It's solid
- BMI value has been written with both rom function called from user program and memtool
- Documentation has been solid and I could doubt it only for 0.5seconds
- Chip has been changed
- Debugging doesn't work anymore

So time to start openocd debugging(instead of jlink debugging) with another probe and low and behold it identifies the target and I fly the binary in it and got the changes I wanted after testing.
XMC 2GO (ab)used as 5v debugger probe served me just long enought to catch hopefully the last bug and fine tune program parameters.
As I have production related functionality to implement maybe I need to figure out how to make openocd session work like it should before distributor sends me more xmc 2gos  (Or then I get that isolated XMC JLink)

Interesting detail: XMC1100 has SRAM parity check reset, Flash ECC reset, USIC(serial communication beast) ram parity reset and Clock Loss interrupt or reset. Also lockup reset in case of double hardfault. This MCU is 100% serious about performing zero unaccounted instructions, using erronous data or not executing required operations for critical task.

Interesting detail: XMC1100 has fixed(from user point of view) vectors. After startup software is completed vectors are remapped. Initial SP is loaded from flash offset 0x0 and Reset handler vector points to 0x4 flash offset that is location of first instruction to execute(EDIT: nope. 0x4 is where reset handler vector is actually). Other vectors point to slots of size of 0x4 in the RAM. That is why you can find these interesting veneers in startup file.
(reconstruction)

Code: [Select]

    .globl X_Veneer
X_Veneer:
    LDR R0, =X_Handler
    MOV PC,R0
    .long 0
    .long 0
These are thumb instructions so it only takes 4 bytes(size of the slot) to enter the handler itself. Those zeros in this particular case after it are reserved slots maybe for MCU with another type core or something. See Reference manual page 64 and forward.

Interesting detail: XMC1100 doesn't have read protection to user program flash but when it's done - it's done. You lock it with BMI in production and combined with the fact that cortex m0 doesn't have VTOR for implementing bootloader in any sane way you should concider the chip unmalleable after that.
This particular detail should further define the chip and it's range of applications in production.

[jonroger]

For me, a "good" MCU is highly dependent on user community, support, libraries and compiler.   Rarely is it about better specs or price.

[jannek]

Sorry guys,

I planned to post this months and months ago.

I made custom OpenOCD "ocd_process_reset_inner" for XMC1100 that actually works.
Normal reset halt; causes CPU to halt in ROM based initial reset handler. Datasheet makes it clear that you are locked out while ROM executes so only option is to power cycle the target to recover.
So in this version in case of reset halt; breakpoint is set to user program entry point and only reset is used.

Please use as you wish. I hope someone would update this to OpenOCD project. It also has "read_xmc_bmi" that works and "write_xmc_bmi" that is not finished.

xmc1100.cfg

Code: [Select]

transport select swd

set CHIPNAME xmc1100
set WORKAREASIZE 0x4000
set APPLICATION_FLASH_START_ADDR 0x10001000
set APPLICATION_FLASH_END_ADDR 0x10010FFF
set APPLICATION_RESET_HANDLER_VECTOR_ADDR 0x10001004
source [find target/xmc1xxx.cfg]

reset_config none
cortex_m reset_config sysresetreq
adapter_khz 10000

#Override reset procedure to archive correct operation of halt after reset


proc ocd_process_reset_inner { MODE } {
global _TARGETNAME
global APPLICATION_FLASH_START_ADDR
global APPLICATION_FLASH_END_ADDR
global APPLICATION_RESET_HANDLER_VECTOR_ADDR

if { 0 != [string compare $_TARGETNAME [target names]] } {
return -code error "XMC1100 reset can handle only one $_TARGETNAME target";
}
set t $_TARGETNAME

# If this target must be halted...
set halt -1
if { 0 == [string compare $MODE halt] } {
set halt 1
}
if { 0 == [string compare $MODE init] } {
set halt 1;
}
if { 0 == [string compare $MODE run ] } {
set halt 0;
}
if { $halt < 0 } {
return -code error "Invalid mode: $MODE, must be one of: halt, init, or run";
}

$t invoke-event reset-start
$t invoke-event reset-assert-pre
$t arp_examine
$t arp_halt
# Catch, but ignore any errors.
catch { $t arp_waitstate halted 5000 }

# Did we succeed?
set s [$t curstate]

if { 0 != [string compare $s "halted" ] } {
return -code error [format "TARGET: %s - Not halted" $t]
}

# Let's read where application entry point resides
mem2array APPLICATION_RESET_HANDLER_ADDR_ARRAY 32 $APPLICATION_RESET_HANDLER_VECTOR_ADDR 1

# Because cortex m0 supports thumb instruction set only we need to substract -1 (LSB) from "thumb pointer" to get the absolute address
set APPLICATION_RESET_HANDLER_ADDR [format 0x%x [incr APPLICATION_RESET_HANDLER_ADDR_ARRAY(0) -1] ]

set ENTRY_POINT_RESIDES_IN_APPLICATION_FLASH 1
#Check that we have sane address for the first application instruction to be executed
if { ( $APPLICATION_RESET_HANDLER_ADDR < $APPLICATION_FLASH_START_ADDR ) || ( $APPLICATION_RESET_HANDLER_ADDR > $APPLICATION_FLASH_END_ADDR ) } {
set ENTRY_POINT_RESIDES_IN_APPLICATION_FLASH 0
}

#Set breakpoint to reset handler if halt is required and breakpoint can be set in application flash address
if { $ENTRY_POINT_RESIDES_IN_APPLICATION_FLASH } {
if  { $halt } {
echo "XMC1100 Halt after reset: Setting breakpoint to first instruction of reset handler(entry point) to archive halt after reset."
bp $APPLICATION_RESET_HANDLER_ADDR 2 hw
} else {
rbp $APPLICATION_RESET_HANDLER_ADDR
}
} else {
echo "XMC1100 Halt after reset: Address for reset handler(entry point) doesn't reside in application flash and breakpoint cannot be set. Doing reset; halt; instead of reset halt"
}


#Reset without halt to not use vector catch
$t arp_reset assert 0

$t invoke-event reset-assert-post
$t invoke-event reset-deassert-pre

$t arp_reset deassert 0

$t invoke-event reset-deassert-post

# Pass 1 - Now wait for any halt (requested as part of reset
# assert/deassert) to happen.  Ideally it takes effect without
# first executing any instructions.
if { $halt } {
if {!$ENTRY_POINT_RESIDES_IN_APPLICATION_FLASH} {
$t arp_waitstate running 200
$t arp_halt
}
catch { $t arp_waitstate halted 1000 }

# Did we succeed?
set s [$t curstate]

if { 0 != [string compare $s "halted" ] } {
return -code error [format "TARGET: %s - Not halted" $t]
}

}

#Remove breakpoint used for halting after reset
if {$ENTRY_POINT_RESIDES_IN_APPLICATION_FLASH} {
rbp $APPLICATION_RESET_HANDLER_ADDR
}

#Pass 2 - if needed "init"
if { 0 == [string compare init $MODE] } {
set err [catch "$t arp_waitstate halted 5000"]

# Did it halt?
if { $err == 0 } {
$t invoke-event reset-init
}
}

$t invoke-event reset-end
}


set XMC_BMI_ADDR 0x10000E00

array set XMC_BMI_MODES_ARRAY {
0xffc0 "ASC Bootstrap Load Mode (ASC_BSL)"
0xf8c1 "User Mode (Productive)"
0xf8c3 "User Mode (Debug) SWD0"
0xfac3 "User Mode (Debug) SWD1"
0xf9c3 "User Mode (Debug) SPD0"
0xfbc3 "User Mode (Debug) SPD1"
0xf8c7 "User Mode (HAR) SWD0"
0xfac7 "User Mode (HAR) SWD1"
0xf9c7 "User Mode (HAR) SPD0"
0xfbc7 "User Mode (HAR) SPD1"
}

proc read_xmc_bmi {} {
global _TARGETNAME
global XMC_BMI_ADDR
global XMC_BMI_MODES_ARRAY

set t $_TARGETNAME

echo "Reading XMC BootModeIndex"
catch { $t arp_waitstate halted 1000 }

# Did we succeed?
set s [$t curstate]

if { 0 != [string compare $s "halted" ] } {
return -code error [format "TARGET: %s - Not halted" $t]
}

#Get BMI
mem2array XMC_BMI_VALUE_FROM_TARGET_ARRAY 16 $XMC_BMI_ADDR 1
set XMC_BMI_VALUE_FROM_TARGET [format 0x%x $XMC_BMI_VALUE_FROM_TARGET_ARRAY(0)]


if {[info exists XMC_BMI_MODES_ARRAY($XMC_BMI_VALUE_FROM_TARGET)]} {
return "BMI Value: $XMC_BMI_VALUE_FROM_TARGET - $XMC_BMI_MODES_ARRAY($XMC_BMI_VALUE_FROM_TARGET)"
} else {
return -code error [format "BMI Value: $XMC_BMI_VALUE_FROM_TARGET - Unknown"]
}
}

#proc write_xmc_bmi { param_bmi } {
# echo "Writing XMC BootModeIndex"
# catch { $t arp_waitstate halted 1000 }

# Did we succeed?
# set s [$t curstate]

# if { 0 != [string compare $s "halted" ] } {
# return -code error [format "TARGET: %s - Not halted" $t]
# }


##TODO
##Check parameter is valid
##Call rom function to write BMI
##reset halt; maybe?
##quit openocd maybe as connection to target is most likelly lost?

#}





Calling commands: "init; reset halt; read_xmc_bmi". Target is XMC2GO board.

Code: [Select]

C:\Program Files\GNU MCU Eclipse\OpenOCD\0.10.0-12-20190422-2015>.\bin\openocd.exe -f .\scripts\interface\jlink.cfg -f .\scripts\target\xmc1100.cfg -c "init; reset halt; read_xmc_bmi"
GNU MCU Eclipse OpenOCD, 64-bitOpen On-Chip Debugger 0.10.0+dev-00593-g23ad80df4 (2019-04-22-20:25)
Licensed under GNU GPL v2
For bug reports, read                                                                                                                                                                                                      [url]http://openocd.org/doc/doxygen/bugs.html[/url]
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
adapter speed: 10000 kHz
read_xmc_bmi
Info : J-Link Lite-XMC4200 Rev.1 compiled Oct 27 2015 17:41:01
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : Reduced speed from 10000 kHz to 3000 kHz (maximum).
Info : Reduced speed from 10000 kHz to 3000 kHz (maximum).
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x0bb11477
Info : xmc1100.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections
XMC1100 Halt after reset: Setting breakpoint to first instruction of reset handler(entry point) to archive halt after reset.
breakpoint set at 0x10001018
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10001018 msp: 0x20000520
Reading XMC BootModeIndex
BMI Value: 0xfac3 - User Mode (Debug) SWD1
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
shutdown command invoked