How to issue the resets required by FDCAN Bootloader on H7 dual cores?

[TOlli]

Hi,

We are currently using H745 in our design and we noticed this little excerpt in the bootloader manual (AN2606):

" Additional reset needed after power off/on to enable connection to the BL interfaces "

It seems that not all resets are equal and the reset is counted towards this requirement if the reset is applied when the chip is already waiting in the bootloader.

Currently, our procedure is this (we use STLink v3:

•    go to debug mode
•    Issue three resets (debug configuration has this assigned to HWReset) with Keil uVision IDE
•    Press "Run Code" to run our application
•    After this, we issue our "Enter bootloader command" (as explained in the article by ST)
•    The controller is ready to enter bootloader and is stopped
•    We press "run code" and the board enters bootloader
•    We can use FDCAN commands

As you can see, we rely on the IDE to get us to a functioning bootloader. We need to be able to do this programmatically.

Any idea on how this could be done?

We have also done this in a different way:

•    Let the board start in a normal environment with the debug adapter attached (no IDE involved in this stage)
•    Issue "Enter bootloader command"
•    Reset the board using STM32CubeProgrammer for example
•    The controller is responding to FDCAN bootloader commands

We have set both of the cores to boot simultaneously and CM4 just waits in main (we use semaphores to block the progress) until CM7 has finished configuring the system.

We have access to Boot0 pin programmatically, but unfortunately, we have left the nRST pin unconnected (only connection is to jtag).

Also, there might be mistake in the AN2606 in picture 58, FDCAN is not passed this briefly, I think the state machine loops back to it like with the rest of the interfaces.

I appreciate any insight into this, if someone has already tackled the issue.

Best regards,

Tero

[TOlli]

@Imen DAHMEN​ , Maybe you could at least check the AN2606 figure 58 if it is like it should be?

[Imen.D]

Hello @TOlli​ ,

Thanks for reporting the mistake in the AN2606.

You are right, in the STM32H7 figures 57-58-59, the return loop from "USB cable detected" goes back to UART condition, but it should go back to FD-CAN condition instead.

The update of the AN2606 is on-going (Rev48) and it will be published in a few days.

The FDCAN and CAN protocols are totally different. You can refer to the AN5348 FDCAN peripheral on STM32 devices:

Note that the ST-link V3 supports CAN bootloader and does not support FDCAN.

So, you should implement a host software that supports FDCAN.

Imen

[TOlli]

Hi,

We are able to interface with the card using a Ixxat CAN-FD USB adapter. So the communications are working good. But we have to use the ST-Link adapter to issue the extra resets (upon connection, the adapter briefly pulls the pin low, issuing a reset through the jtag connector to nRST pin) required by ST bootloader FW so that the CAN gets configured properly by the bootloader.

My question is, what is the recommended way of issuing these resets programmatically without using the ST-Link adapter?

Best regards

[TOlli]

Hi @Imen DAHMEN​ ,

Would you happen to have a contact info for one of your colleagues that could help?

Maybe someone who worked on the FDCAN Bootloader so we can ask specific questions on how to get this working.

Best regards,

Tero

[Imen.D]

​Hi @TOlli​ ,

I escalated your request to the expert team. But, no sure to catch exactly your issue.

>> We are able to interface with the card using a Ixxat CAN-FD USB adapter. So the communications are working good. 

On this you said it’s working ? But you are still trying to reset?

How can this be done ?

Can you please provide more clarification about your case?

Imen

[TOlli]

Hi,

So if I manipulate the nRST pin manually (to issue the extra reset required by the Bootloader), we are able to use the commands defined in the bootloader manual.

But we can't have a manual reset requirement for entering the bootloader. In the real application, the user will only have access to the CAN connector and not much else. So we need a fully programmable approach to entering the bootloader.

Right now, what happens is:

• we power up the board, it boots and starts running our application
• We issue our own command (we use CAN ID 0x105) using FDCAN1 to the board so that it initiates transition to the bootloader
• The application makes it possible to switch to the bootloader by putting Boot0 pin high (we have a RC delay circuit on this, so it stays up for a few ms)
• The application issues HAL_NVIC_SystemReset()
• Because boot0 is still one, the board tries to load from 0x1ff0 which is empty and enters the bootloader
  • At this stage, the bootloader does not work. This is due to the missing resets referenced in the AN206
• I, personally, using my hands and jumper cables, issue a reset by pulling nRST low on the board
  • There is no way for the processor to do this, since it is in the bootloader and we are unable to write a program to manipulate the IO
• The board enters back to normal application (boot0 is 0 at this stage already because we took our time)
• We issue CAN ID 0x105 again
• The application makes it possible to switch to the bootloader by putting Boot0 pin high (we have a RC delay circuit on this, so it stays up for a few ms)
• The application issues HAL_NVIC_SystemReset()
• Because boot0 is still one, the board tries to load from 0x1ff0 which is empty and enters the bootloader
  • The bootloader now responds to CAN commands like 0x0 (get info) etc. using the settings referenced in the applications notes

How do we do this without me physically and manually fiddling with jumper wires to issue the reset when the board is in bootloader and we don't have access to the GPIO?

We are using STM32H745/STM32H755.

For example, in the F7 series, when you enter the bootloader, it is enough for us to send 0x79 (STM designated command, not ours) to the board using CAN and the board is able to configure itself and excepts bootloader commands.

Back to the H7 bootloader:

Why are the processes different compared to F7 for example and how was this designed like this? And how did ST RnD plan on for its customers to be able to use this programmatically? Are we issuing wrong kind of resets or what's the reason I have to issue manual, outside wiring pulling the nRST low at specific points, just to make the bootloader respond to commands.

[TOlli · Accepted solution]

If someone happens to stumble on this same topic, here is what I found out (since there is no official contact here from ST or @Imen DAHMEN​ anymore):

I was not able to find out how the resets are to be issued ( even through the official support channels by creating a separate case ), it is impossible for them to test this out since all their nucleo and dev boards don't have the correct pins pulled out to CAN interfaces. Only possibility was to use a RC circuit to "charge" the Boot0 pin to hi and issue a reset. Do this twice and on the second go, the bootloader and can will be able to answer correctly.

Important to note, I was told that the reset is only needed for the power to the chip to be stabilized (powering up and entering the bootloader should not happen at the same time. what same time means, was not specified), but after using numerous industrial power sources and having amble time between powering the chip (everything should stabilize by then, unless there is an internal discrepancy during reset of the chip), I could not get rid of the resets required.

Second issue, and this is a deal breaker: There is a hard limit (it says so in the bootloader documents) of writing 63 bytes per bank. After that, it does not write anything anymore. And there is nothing you can do about it. I didn't test exiting and entering the bootloader again after each 63 bytes to see if it would reset, but I don't think that is feasible option.

I also got an official response that ST is not going to fix this issue. So stay away from their CAN-FD based bootloader, since it does not work and they will not fix it.

I wish they would be more clear about the issue, it's not that writing more than 63 bytes per command is not working, but that it is the total number of bytes that will work.

Best regards,

Tero