MCU-PLUS-SDK-AM243X: Bootloader From DFU Tool

Hi Hao,

Could you confirm if you are using SBL DFU  for this, if yes then please let me know which SBL image and which application image you are using. Also, please attach the UART logs if available.

Best Regards,

Meet.

Meet

I am using SBL DFU for this. The file being used is sbl_dfu.release.hs_fs.tiimage.

Before execution, the AM64x DFU can be seen in Device Manager.

After running it disappered.

The CMD log is:

I need to identify how to return the control back to USB after DFU execution.

Thanks.

Thanks & Best regards

Hao (Wang hao)

Hi Hao,

Could you please try this command and see if it works:

dfu-util -R -i 0 -a 0 -D {path to sbl_dfu} and see if it works.

-R here issues USB reset signalling after upload or download has finished.

Best Regards,

Meet.

Meet

Thanks for reply.

I have tried the command. It does not work either.

I found the root cause.

Before run the DFU load command, the DFU info is:

After run the SBL DFU command, it changed to:

The IDs and serial number are changed.

I do not understand what the SBL DFU have done. 

I can try to fix this by recreate and reinstall the INF driver. Then to make the Device Manager recognize it again without power cycle the board.

But when I run the DFU command to load my app image following above actions, e.g. Hello World image in example library.

The DFU device disappeared in Device Manager, and cannot be recalled by reinstallation, unless power cycle the EVM board.

It seems the DFU load command cannot run the second time, it makes the DFU device lost to be recognized by Device Manager.

This is not what I expect, I need to boot the Soc by SBL DFU and then load my app image, without power cycle the board.

Because there is not flash in my custom board, I have to boot the Soc and load my firmware to RAM by USB DFU during every powerup, then communicate the Soc by USB port in program.

So it is important for me to implement above loading requirement.

Appreciate for any suggestion.

Thanks.

Thanks & Best regards

Hao (Wang hao)  

Hi Hao,

I will try to test the same at my end and let you know if I can reproduce this.

Best Regards,

Meet.

Meet

Can I know if there is update on this?

Thanks.

Thanks & Best regards

Hao (Wang hao)

Hello,

Hao Wang said:

After run the SBL DFU command, it changed to:

After this, you would just need to send your application image. The SBL DFU would receive & boot the image. If the UART logging is enabled, you should see the UART logs.

Regards,

Prashant

Prashant

Thanks for response.

I have tried to run the SBL DFU command and then send the application image as you recommended.

Before the SBL DFU command, the DFU can be found.

The logs for SBL DFU and load image are as below.

It looked the loadings are successful.

But when run dfu-uitl --list again, the DFU disappeared.

The Soc cannot be talked through USB DFU after the loadings.

Can you please help to identify the bug if you can reproduce above?

Thanks.

Thanks & Best regards

Hao (Wang hao)

Hao Wang said:

It looked the loadings are successful.

But when run dfu-uitl --list again, the DFU disappeared.

This is expected.

The SBL DFU is a bootloader that loads a single appimage over DFU & boots it. So, after you send the "hw.appimage" over DFU, the SBL DFU would boot the appimage so you won't see anything for "dfu-util -l" again.

Prashant

I will use the USB DFU functions to communicate with Soc in my application.

Is there solution to recognize DFU again after the loading other than power cycle the Soc?

I think it is not very reasonable for users if they need to use the functions from USB class with USB cable attached to custom board in application.

If there is no flash in my custom board, the firmware needs to be loaded to RAM in every powerup, then this would be a bug.

I have tried to reset DFU by command but does not work.

Can you please share good solutions?

Thanks.

Thanks & Best regards

Hao (Wang hao)