Hold a pin low after CPU reset? Bootloader issues

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

cross mob
User15596
Level 2
Level 2
Using XMC1404, CAN BSL on Channel1, a CAN transceiver with standby where an internal pull-up keeps it in "off" mode.


I'd like to use the CAN BSL to load a secondary bootloader that updates my module's flash. However... In order to use CAN I need to drive the STANDBY pin on my transceiver low. This is something the CAN BSL won't know how to do, this slave device will not be able to transmit to the re-programming host.


I see two options.

1. I need to set the transceiver standby pin low before changing the mode from USER PRODUCTIVE to CAN BSL. As I understand it, the moment I do this, the flash is wiped, registers are set back to default, and the CPU requests a reset into CAN BSL mode. I'm not sure if I can hold a pin low and expect it to stay low after a reset like this. I would need to overcome the transceiver's internal pullup on it's standby pin, I can find no stated behavior on GPIO pins during a mode change from UPM to BSL.

2. If I could somehow boot into ALTERNATE BOOT MODE, this would be less of an issue. As I understand it, ABM is my own bootloader set to a very specific address, where I could simply set the standby pin low with my own code. However, this mode appears to be exclusively available via reading the BOOT0/1 pins only. I do not see a way to load into ABM from software BMI... for some reason.

So...

Is there a way to hold a pin low during reset and mode change?

Is it perhaps possible to put manipulate the BOOT0/1 pins? Using them as GPIOs to charge a capacitors then immediately select "USE PINS" and hope I get to ABM before the voltage falls?

Any other options besides adding a latching buffer to keep that line held down? (I likely do not have the room to add a part for this)

Any other options?
0 Likes
5 Replies
User15596
Level 2
Level 2
I don’t know what the Infineon hours are for the holidays, but I’m actively checking in here.
0 Likes
User14604
Level 4
Level 4
First solution authored
There's not much activity of Infineon staff in this board. Please don't rely on that 😉

I'm not sure if I understood your original questions, so please correct me if I got your wrong:
1. I don't see a way to put a pin into a specific state after reset. Pin state after reset is defined by default register values, probably there's no way around.
2. It seems switching to any mode is more difficult with the XMC14xx than with XMC4xxx. Nevertheless the manual says:
Start-up mode selection in XMC1400 is done by the SSW after reset. For the first start-up, it is based on Boot Mode Index (BMI) stored in flash configuration sector 0 (CS0). Subsequently, there is also an option to boot via pins by programming BMI.PINDIS with 0. Upon master reset, the values at at the boot pins P4.6 (STSTAT.HWCON[0]) and P4.7 (STSTAT.HWCON[1]) are latched in.
Does that mean that you can decide to boot up your device in ABM mode by just writing the correct bytes to flash? (see chapter 27.2.2)
If so, just start your device in ABM on every start-up, then let your custom loader decide whether to receive new app and run the actual flash routines OR to run the app itself.
0 Likes
User15596
Level 2
Level 2
There's not much activity of Infineon staff in this board. Please don't rely on that 😉


No doubt.

1. I don't see a way to put a pin into a specific state after reset. Pin state after reset is defined by default register values, probably there's no way around.


Yea, it seems you get the idea. That in order for CAN transceiver to come on, I need to hold a pin low, and if it's in CAN BSL mode, the pin won't be held. So unless I can assert it and get it to stay there between a reset - and further a reset from UserProductiveMode to CAN BSL mode which is supposed to reset the entire chip and flash to default settings. I agree, I haven't seen a way to do this. I was hoping for a "lock" that would persist between single resets and the factory reset..

Start-up mode selection in XMC1400 is done by the SSW after reset. For the first start-up, it is based on Boot Mode Index (BMI) stored in flash configuration sector 0 (CS0). Subsequently, there is also an option to boot via pins by programming BMI.PINDIS with 0. Upon master reset, the values at at the boot pins P4.6 (STSTAT.HWCON[0]) and P4.7 (STSTAT.HWCON[1]) are latched in. Does that mean that you can decide to boot up your device in ABM mode by just writing the correct bytes to flash? (see chapter 27.2.2) If so, just start your device in ABM on every start-up, then let your custom loader decide whether to receive new app and run the actual flash routines OR to run the app itself.


So.. yea, the 1xxx series does seem a little more difficult than the 4xxx. You have it mostly right and I appreciate you taking a look! Yes, the SSW (startup software) will load BMI register. And if you set PINDIS to 0 (enable pins) the next restart will "listen" to the pins and put it in that mode.

Thing is... According to 27.2.2 which I've attached a snip of, won't allow me to get to Alternative Boot Mode. According to my read of the sheet you can ONLY enter that though pins. There doesn't seem to be a way to get there via software.

3372.attach

Right, so there is a chance this is available via a "reserved" setting, but unlikely.

I think you're on to something with starting in ABM always. Which is sort-of possible if I configure the BOOT0/1 pins to be low/high respectively, the first flash via SWD would require the ABM code that typically jumps to "normal code" every boot. The issue with that is I'll need to configure the board hardware to be ABM on the pins which fine but locks in the board and assembly a specific way.

EDIT: Nope. I realized why this didn't work. I can't always boot into Alternate Boot Mode where my working bootloader could exist then switch to normal firmware. The issue is I need to be in User Productive Mode (code protect and swd disable) during normal use. I can only be outside of UPM mode when the firmware is empty, which is why moving from UPM to any other mode does a full chip reset. So... thinking about it, the only way ABM would work is if while in UPM mode the flash is cleared but the SRAM is not.
0 Likes
User14604
Level 4
Level 4
First solution authored
Hello S.R.,

if PINDIS in BMI is set to 1, the SSW should select the Boot Mode selected by BMI, which in that case will get populated only by flash, but not by hardware. Is that correct?

So, if I understand correctly, the problem arises to start the ABM, because that requires you to switch back to PINDIS = 0 and set the pins correctly, does it? (Sorry if it took me a long time to realize what's the problem of 14xx series ...)

If that's the case, I'd fully skip ABM and resort to a fully custom bootloader concept:
Place your bootloader in your first logical flash sector, where your application in User Mode would be placed, so that it will be started by SSW. Let it decide whether to actually perform CAN bootloader actions (0) or to start-up the application (1). For example, the bootloader could still check a specific header (similar to ABM) for application area and start it. If application header exists and is valid, reload application RAM contents, reset stack pointer, remap vectors to new RAM/ROM address and jump to application. Haven't tried it with XMC devices, but we did it with some Cortex M3 and its predecessors. Should be possible.

In case ABM seems to be the better way for you, I didn't understand the following. Could be I only have a basic idea how UPM works:

The issue with that is I'll need to configure the board hardware to be ABM on the pins which fine but locks in the board and assembly a specific way.

EDIT: Nope. I realized why this didn't work. I can't always boot into Alternate Boot Mode where my working bootloader could exist then switch to normal firmware. The issue is I need to be in User Productive Mode (code protect and swd disable) during normal use. I can only be outside of UPM mode when the firmware is empty, which is why moving from UPM to any other mode does a full chip reset. So... thinking about it, the only way ABM would work is if while in UPM mode the flash is cleared but the SRAM is not.


My interpretation: The problem is switching between bootloader (ABM) and UPM is not safe. Although switch from ABM to UPM is easy by re-programming PINDIS bit, switching back the PINDIS requires you to edit it while you are in UPM, which is impossible?
If you need UPM for code write-disable capability only, you could write-disable the sectors in bootloader during flash operation (see NVMCONF.SECPROT).
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

As you already found out there is no way to keep the pin driving low when switching the BMI from UPM to CAN BSL.
Proposal from ErnieT, integrating the firmware upgrade routine into your application running in UPM would be the more suitable, which is equivalent to boot via pins where ABM is used. The benefit of the bott via pins is that you could update even the firmware upgrade routine.

How do you intend to trigger the start of firmware upgrade? After receiving a certain CAN message? or only after reset with a timeout?

BTW: The pin P0.14 is pulled up during standard bootstrap loader modes (UART, CAN). I know it is not the level you need but...

Regards,
Jesus
0 Likes