AM2432: usb_dfu_uniflash.py hangs at Waiting for DFU device to be enumerated .

1) We verified the same raspberry pi image (tested on both Linux and Raspberry PI OS) is able to run the usb_dfu_uniflash.py properly on TI's EVM board. 
2) We verified on our board, we are able to use usb_dfu_loader.py to load hello world project and run it successfully 
3) At the above hang state, if we power cycle the board, the script will continue to run, but since it lost sbl_dfu_uniflash in RAM, it will not program any image into boot flash. 

Hello,

Hong Zhang said:

2) It always hang as below at Waiting for DFU device to be enumerated .

If this is the case, there is a very good probability that the SBL_DFU_UNIFLASH is booting but gets stuck somewhere, probably in the initialization of the custom flash, before it could expose the DFU interface to receive the other images.

If you have the means to connect debugger to your board, could you please use it to connect to the R5FSS0-0 core & see the address it is suspended at. If it's 700xxxxx something then the SBL is booting. If it's 0x41xxxxxx then the ROM failed to boot SBL. In the former case, you could then load the SBL's symbols to know the exact point at which the control is stuck.

Hello Prashant, 

Thanks a lot for the reply. 

I tested the same image that is used by sbl_dfu_uniflash.py via UART boot, and verified that it is able to write/read from the boot SPI flash.  But when the same image is downloaded via sbl_dfu_uniflash.py, it hanged most of the time at Waiting for DFU device to be enumerated ...... At one time, it did go through all the three files, but AM243 still failed to boot the image that is supposed to be flashed.  

I don't have a XDS-110 debugger to be available on this setup as it is now. 

Thanks,

Hong 

Hello Prashant, 

I enabled UART debug print in the sbl_dfu_uniflash project, and I was able to print to see that it entered dfu_task from the print. I also tested the custom flash write/read from the same sbl_dfu_uniflash project, and it was able to write/read the flash after sbl_dfu_uniflash project was downloaded into RAM. 

/* Main DFU task */
int dfu_task(void)
{
DebugP_log("Entered dfu_task");   => I see this debug print on the UART console. 
while (1)


But the script side just hangs at 
Waiting for DFU device to be enumerated ....

Thanks, 
Hong 

I also noticed that dfu-util can only detect the device after we issue power cycle on the board or disconnect + reconnect the USB cable.  After the above test failed the dfu-util is not able to detect the device any more until next power cycle. 

Hong 

I also noticed there are two occasions that the script showed successfully run, but it still failed to program the flash. 

 sudo python3 usb_dfu_uniflash.py --cfg default_dfu_ospi.cfgParsing config file ...
Parsing config file ... SUCCESS. Found 3 command(s) !!!Executing command 1 of 3 ...
Found flash writer ... sending sbl_dfu_uniflash_0900.hs_fs.tiimage
----------------------------------------------------------------------------
Executing DFU command with alt_setting=0 interface=0 transfer_size=512
----------------------------------------------------------------------------
dfu-util 0.11Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6165
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 512
Warning: Overriding device-reported transfer size
Copying data from PC to DFU device
Download [=========================] 100%    350628 bytes
Download done.
DFU state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Sent flashwriter sbl_dfu_uniflash_0900.hs_fs.tiimage of size 350628 bytes in 1.55s. Bandwidth = 220.91kbpsExecuting command 2 of 3 ...
Command arguments : --file=bootloader_am243_debug.hs_fs.tiimage --operation=flash --flash-offset=0x0
------------------------------------------------------
Waiting for DFU device to be enumerated ....
------------------------------------------------------
----------------------------------------------------------------------------
Executing DFU command with alt_setting=0 interface=0 transfer_size=512
----------------------------------------------------------------------------
dfu-util 0.11Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6165
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 512
Warning: Overriding device-reported transfer size
Copying data from PC to DFU device
Download [=========================] 100%    366500 bytes
Download done.
DFU state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Sent bootloader_am243_debug.hs_fs.tiimage of size 366468 bytes in 1.57s. Bandwidth = 227.95kbps
True
Executing command 3 of 3 ...
Command arguments : --file=appimage.bundle --operation=flash --flash-offset=0x80000
------------------------------------------------------
Waiting for DFU device to be enumerated ....
------------------------------------------------------
----------------------------------------------------------------------------
Executing DFU command with alt_setting=0 interface=0 transfer_size=512
----------------------------------------------------------------------------
dfu-util 0.11Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6165
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 512
Warning: Overriding device-reported transfer size
Copying data from PC to DFU device
Download [=========================] 100%    398144 bytes
Download done.
DFU state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Sent appimage.bundle of size 398112 bytes in 1.62s. Bandwidth = 239.99kbps
True
All commands from config file are executed !!!

From the host side, the error message is -110 as below. 

dmseg | tail

[38032.787965] usb 1-1.3: device descriptor read/64, error -110

[38032.979996] usb 1-1.3: new high-speed USB device number 74 using dwc2

[38038.163983] usb 1-1.3: device descriptor read/64, error -110

[38053.780017] usb 1-1.3: device descriptor read/64, error -110

[38053.892178] usb 1-1-port3: attempt power cycle

[38054.500015] usb 1-1.3: new high-speed USB device number 75 using dwc2

[38065.172048] usb 1-1.3: device not accepting address 75, error -110

[38065.256045] usb 1-1.3: new high-speed USB device number 76 using dwc2

[38075.924077] usb 1-1.3: device not accepting address 76, error -110

[38075.930548] usb 1-1-port3: unable to enumerate USB device

Hello TI team, 

Is there a way to force AM243 to operate at full-speed mode and disable high-speed mode? 

Thanks,
Hong 

Hi Hong,

I think the best (and may be only) way to do it is to use a USB hub that has full-speed port and use it to connect to the AM243x board. 

regards,

Michael

Hello TI team, 

For this USB usb_dfu_uniflash.py issue, we tried TI’s suggestion to update the resistor values.

We tried different host pi3, pi4 and linux box.

We verified that the sbl_dfu_uniflash binary started to run properly and was able to writ/read into SPI flash. It didn’t hang and entered dfu_task properly.

We measured the signals via scope, and the signal is clean.

With all the above effort, the host still failed to enumerate the device after running sbl_dfu_uniflash image with usb 1-1.3: device descriptor read/64, error -110

Any help is appreciated. 

Hong 

On host side,  what is the proper driver to talk to the device, should host use dwc_otg or dwc2? 

Hong 

Using different host, the same board can be identified to use dwc_otg driver or dwc2 driver. Both failed at the same -110 error. 

[250553.155379] usb 1-1.1.2: new high-speed USB device number 82 using dwc_otg

[250553.286640] usb 1-1.1.2: New USB device found, idVendor=0451, idProduct=6165, bcdDevice= 2.00

[250553.286665] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[250553.286681] usb 1-1.1.2: Product: AM64x DFU

[250553.286696] usb 1-1.1.2: Manufacturer: Texas Instruments, Inc.

[250553.286711] usb 1-1.1.2: SerialNumber: 01.00.00.00

[250575.388308] usb 1-1.1.2: USB disconnect, device number 82

[250576.195481] usb 1-1.1.2: new high-speed USB device number 83 using dwc_otg

[250581.375384] usb 1-1.1.2: device descriptor read/64, error -110

[250596.735382] usb 1-1.1.2: device descriptor read/64, error -110

[250596.955384] usb 1-1.1.2: new high-speed USB device number 84 using dwc_otg

Hong

Hello Hang,

Thank you for your patience.

Allow me a day to read through all your responses and conversations.

Regards,

Vaibhav

Hello Hong,

Thank you very much for your patience.

I have gone through your responses and I am summarizing all of the above context here:

1. SoC: AM243x, Flash: Custom Flash(Question: What is the name of the custom flash)
2. MCU PLUS SDK AM243x 9.00.00.35: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/09_00_00_35/exports/docs/api_guide_am243x/index.html
3. Using sbl_dfu_uniflash.py and the configuration file default_dfu_ospi.cfg(Request: Can you please attach the config file here on e2e and let me know what each of the images are supposed to do: sbl_dfu_uniflash_0900.hs_fs.tiimage,  bootloader_am243_debug.hs_fs.tiimage and appimage.bundle)
4. Hong already verified that:
   1. Writing to the flash works
   2. Reading from the flash works
5. Step 4 was verified using UART Bootmode(Question: Did you use the uart_bootloader.py script for this)
6. But using the script sbl_dfu_uniflash.py with the config file default_dfu_ospi.cfg results in either of the two ways:
   1. Most of the times it hangs at "Waiting for DFU device to be enumerated ...." after flashing the first image itself, and the rest 2 images are not flashed.
   2. Very rarely all the three images(mentioned in default_dfu_ospi.cfg) are flashed but AM243x fails to boot the images that is supposed to be flashed.

Let me know if I missed out anything.

Please respond to the Questions and the Request I asked for.

You can expect a follow up from me post your response.

Regards,

Vaibhav

Vaibhav Kumar said:

• f the times it hangs at "Waiting for DFU device to be enumerated ...." after flashing the first image itself, and the rest 2 images are not flashed.
• Very rarely a

1. SoC: AM243x, Flash: Custom Flash(Question: What is the name of the custom flash). => NOR flash on the OSPI bus, but we only use MOSI and MISO. 
2. MCU PLUS SDK AM243x 9.00.00.35: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/09_00_00_35/exports/docs/api_guide_am243x/index.html
3. Using sbl_dfu_uniflash.py and the configuration file default_dfu_ospi.cfg(Request: Can you please attach the config file here on e2e and let me know what each of the images are supposed to do: sbl_dfu_uniflash_0900.hs_fs.tiimage,  bootloader_am243_debug.hs_fs.tiimage and appimage.bundle)
   

   # First point to sbl_uart_uniflash binary, which function's as a server to flash one or more files

   --flash-writer=sbl_dfu_uniflash_0900.Debug.hs_fs.tiimage

   --file=bootloader_am243_debug.hs_fs.tiimage --operation=flash --flash-offset=0x0

   --file=appimage.rtm_bundle --operation=flash --flash-offset=xxxxx

4. Hong already verified that:
   1. Writing to the flash works
   2. Reading from the flash works
5. Step 4 was verified using UART Bootmode(Question: Did you use the uart_bootloader.py script for this)
   No, I just downloaded the sbl_dfu_uniflash_0900.Debug.hs_fs.tiimage binary from Teraterm 
6. But using the script sbl_dfu_uniflash.py with the config file default_dfu_ospi.cfg results in either of the two ways:
   1. Most of the times it hangs at "Waiting for DFU device to be enumerated ...." after flashing the first image itself, and the rest 2 images are not flashed.
   2. Very rarely all the three images(mentioned in default_dfu_ospi.cfg) are flashed but AM243x fails to boot the images that is supposed to be flashed.
      
      Please see the inline response as above 
      
      
      Thanks, 
      Hong 

Hello Vaibhav, 

Here is the latest information, I reworked on the sbl_dfu_uniflash project, and proceeded a bit further. 

On the FW side, I could tell that the tud_dfu_manifest_cb enteres this function Bootloader_uniflashProcessFlashCommands(&uniflashConfig, &respHeader); , but it didn't come back from this function. 


On the host side, it failed with LIBUSB_ERROR_TIMEOUT as below.  I suspect our SPI flash might be slower, and I need to the timeout to be 60 seconds, but it failed the same way. 

Thanks a lot for the help,

Hong

  sudo python3 usb_dfu_uniflash.py --cfg default_dfu_ospi.cfg

Parsing config file ...

Parsing config file ... SUCCESS. Found 3 command(s) !!!

Executing command 1 of 3 ...

Found flash writer ... sending sbl_dfu_am243x_uniflash_v8_extra_print.Debug.hs_fs.tiimage

----------------------------------------------------------------------------

Executing DFU command with alt_setting=0 interface=0 transfer_size=512

----------------------------------------------------------------------------

dfu-util -a 0 -i 0 -t 512 -D sbl_dfu_am243x_uniflash_v8_extra_print.Debug.hs_fs.tiimage

dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2021 Tormod Volden and Stefan Schmidt

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to sourceforge.net/.../

dfu-util: Warning: Invalid DFU suffix signature

dfu-util: A valid DFU suffix will be required in a future dfu-util release

Opening DFU capable USB device...

Device ID 0451:6165

Device DFU version 0110

Claiming USB DFU Interface...

Setting Alternate Interface #0 ...

Determining device status...

DFU state(2) = dfuIDLE, status(0) = No error condition is present

DFU mode device DFU version 0110

Device returned transfer size 512

Warning: Overriding device-reported transfer size

Copying data from PC to DFU device

Download [=========================] 100%       351748 bytes

Download done.

DFU state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present

DFU state(2) = dfuIDLE, status(0) = No error condition is present

Done!

Sent flashwriter sbl_dfu_am243x_uniflash_v8_extra_print.Debug.hs_fs.tiimage of size 351748 bytes in 1.38s. Bandwidth = 248.92kbps

Executing command 2 of 3 ...

Command arguments : --file=bootloader_am243_debug.hs_fs.tiimage --operation=flash --flash-offset=0x0

------------------------------------------------------

Waiting for DFU device to be enumerated ....

------------------------------------------------------

----------------------------------------------------------------------------

Executing DFU command with alt_setting=0 interface=0 transfer_size=512

----------------------------------------------------------------------------

dfu-util -a 0 -i 0 -t 512 -D bootloader_am243_debug.hs_fs.tiimage.tmp

dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2021 Tormod Volden and Stefan Schmidt

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to sourceforge.net/.../

dfu-util: Warning: Invalid DFU suffix signature

dfu-util: A valid DFU suffix will be required in a future dfu-util release

Opening DFU capable USB device...

Device ID 0451:6164

Device DFU version 0101

Claiming USB DFU Interface...

Setting Alternate Interface #0 ...

Determining device status...

DFU state(2) = dfuIDLE, status(0) = No error condition is present

DFU mode device DFU version 0101

Device returned transfer size 512

Warning: Overriding device-reported transfer size

Copying data from PC to DFU device

Download [=========================] 100%       366500 bytes

Download done.

DFU state(7) = dfuMANIFEST, status(0) = No error condition is present

dfu-util: unable to read DFU status after completion (LIBUSB_ERROR_TIMEOUT)

dfu_status is:

18944

[ERROR] DFU fw  send failed, no response OR incorrect response from EVM OR cancelled by user,

Power cycle EVM and run this script again !!!

More verbose output when failure occured

Download [=========================] 100%       366500 bytes

Download done.

Sent a total of 366500 bytes

[ 1.867215] [00001157] libusb: debug [libusb_submit_transfer] transfer 0xaaaad97394f8

[ 1.867226] [00001157] libusb: debug [add_to_flying_list] arm timer for timeout in 5000ms (first in line)

[ 1.867250] [00001157] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling

[ 1.867263] [00001157] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms

[ 1.867445] [00001157] libusb: debug [usbi_wait_for_events] poll() returned 1

[ 1.867464] [00001157] libusb: debug [reap_for_handle] urb type=2 status=0 transferred=6

[ 1.867475] [00001157] libusb: debug [handle_control_completion] handling completion status 0

[ 1.867486] [00001157] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer

[ 1.867499] [00001157] libusb: debug [usbi_handle_transfer_completion] transfer 0xaaaad97394f8 has callback 0xffff97161914

[ 1.867511] [00001157] libusb: debug [sync_transfer_cb] actual_length=6

[ 1.867523] [00001157] libusb: debug [libusb_free_transfer] transfer 0xaaaad97394f8

DFU state(7) = dfuMANIFEST, status(0) = No error condition is present

[ 2.867619] [00001157] libusb: debug [libusb_submit_transfer] transfer 0xaaaad97394f8

[ 2.867652] [00001157] libusb: debug [add_to_flying_list] arm timer for timeout in 5000ms (first in line)

[ 2.867696] [00001157] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling

[ 2.867710] [00001157] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms

[ 7.867678] [00001157] libusb: debug [usbi_wait_for_events] poll() returned 1

[ 7.867720] [00001157] libusb: debug [libusb_cancel_transfer] transfer 0xaaaad97394f8

[ 7.867985] [00001157] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer

[ 7.868011] [00001157] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling

[ 7.868023] [00001157] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms

[ 7.868042] [00001157] libusb: debug [usbi_wait_for_events] poll() returned 1

[ 7.868062] [00001157] libusb: debug [reap_for_handle] urb type=2 status=-2 transferred=0

[ 7.868075] [00001157] libusb: debug [handle_control_completion] handling completion status -2

[ 7.868088] [00001157] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation

[ 7.868099] [00001157] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer

[ 7.868112] [00001157] libusb: debug [usbi_handle_transfer_completion] transfer 0xaaaad97394f8 has callback 0xffff97161914

[ 7.868124] [00001157] libusb: debug [sync_transfer_cb] actual_length=0

[ 7.868139] [00001157] libusb: debug [libusb_free_transfer] transfer 0xaaaad97394f8

dfu-util: unable to read DFU status after completion (LIBUSB_ERROR_TIMEOUT)

[ 7.868183] [00001157] libusb: debug [libusb_close] 

[ 7.868199] [00001157] libusb: debug [usbi_remove_event_source] remove fd 7

[ 7.868256] [00001157] libusb: debug [libusb_exit] 

[ 7.868299] [00001158] libusb: debug [linux_udev_event_thread_main] udev event thread exiting

[ 7.868473] [00001157] libusb: debug [libusb_unref_device] destroy device 2.1

[ 7.868493] [00001157] libusb: debug [libusb_unref_device] destroy device 1.16

[ 7.868505] [00001157] libusb: debug [libusb_unref_device] destroy device 1.3

[ 7.868517] [00001157] libusb: debug [libusb_unref_device] destroy device 1.2

[ 7.868528] [00001157] libusb: debug [libusb_unref_device] destroy device 1.1

[ 7.868539] [00001157] libusb: debug [usbi_remove_event_source] remove fd 4

[ 7.868559] [00001157] libusb: debug [usbi_remove_event_source] remove fd 3

dfu_status is:

18944

[ERROR] DFU fw  send failed, no response OR incorrect response from EVM OR cancelled by user,

Power cycle EVM and run this script again !!!

Hello Hong,

Thanks for your updates. I am going to go through these and summarize in a while. We can discuss this in our scheduled call today.

Thanks,

Vaibhav

Hello Hong,

Below is the latest update from you.

Debugging update:

I see that in the expressions tab, there is a loop variable defined. Did you added a loop forever somewhere in the code?

If so can you remove it and do a free run and connect to the R5 core, that way we can know exactly where it is stuck at.

Regards,

Vaibhav

Hello Vaibhav, 

Thanks a lot for the reply. 

Some progress has been made:
1) Added a while loop forever, and connected XDS-100 debugger, dumped the file that was received in RAM. Checked the bootloader was received in RAM via sbl_dfu properly. The SHA is exactly as it should be. 
2) Found out the stack overflow is the issue that caused failures for the Bootloader_uniflashProcessFlashCommands. Fixed the issue by increasing the stack allocation size. 
3) The FW side didn't report any errors after step 2), but still failed at timeout reported by dfu_util. Proceeded further to ignore the timeout to program the second file anyway. Noticed that the images were programmed successfully into SPI flash. 

To be resolved:
Both dfu-util and libusb use a 5 second timeout, which caused the timeout failure. I did recompile the dfu-util with a larger timeout, but have not found where the 5 second timeout is configured in libusb itself. 

Thanks a lot for the help. The debug session is very helpful. 
Hong 

Hello Hong,

Hong Zhang said:

To be resolved:
Both dfu-util and libusb use a 5 second timeout, which caused the timeout failure. I did recompile the dfu-util with a larger timeout, but have not found where the 5 second timeout is configured in libusb itself. 

We have proposed another debug session on wednesday.

Lets have a call and debug this further.

Regards,

Vaibhav

Hello Hong,

Thank you very much for the debug call.

Here is the summary and the next steps for you to debug: (E: Experiments for Hong to run, I: Information as discussed in the meeting)

E1:

Before going ahead with any profiling or experiments, as you mentioned on the call that you are having a quad flash part on AM243 EVM but using the flashFixUpOspiBoot, so I want you to go ahead and use the flashFixUpQspiBoot API instead which is correct for QSPI flash parts and available as part of MCU PLUS SDK 10.0.

Please find the API flashFixUpQspiBoot defined here: https://github.com/TexasInstruments/mcupsdk-core/blob/next/examples/drivers/boot/sbl_ospi/am243x-lp/r5fss0-0_nortos/main.c

Let me know the results of the above experiment.

I1:

Apart from this, you have mentioned that your Image size for bootloader and appimage ~ 300 kbytes each.

E2:

After running the E1 experiment and implementing the changes of using flashFixUpQspiBoot, I want you to run a very simple experiment to test of the flash write and read works absolutely fine or not.

So go ahead and use the following config file at the location: C:\ti\mcu_plus_sdk_am243x_09_02_00_50\tools\boot\sbl_prebuilt\am243x-evm\default_sbl_ospi.cfg

You can comment out the XIP image which is the last image.

For the application image I would suggest you to just replace the ipc_notify_echo with a simple hello world r5 nortos application image.

Make sure to have your bootloader image which you have built.

Once you have made the changes, flash using uart uniflash and pass the modified config file.

After this open the ospi_flash_io example and open SysCOnfig for the project and update the Flash and OSPI tabs with the correct values for the flash part.

I believe this would be a 1s-1s-1s configuration which you will set into SysConfig. Build the ospi_flash_io application.

Once uart uniflash is over, connect to the R5F core and load the .out of the ospi_flash_io and run it. We need the ospi_flash_io to run properly, if it fails to run, then the writes and reads are not happening correctly.

E3:

Repeat the E2 experiment with DMA enabled check for ospi_flash_io.

I2:

Using SPI across all configurations, 1s-1s-1s

SPI Mode 0(CPOL = 0, CPHA = 0)

Input clock frequency: 200 MHz, Divider: 10, effective = 20 MHz, TAP mode

Regards,

Vaibhav

Hong

Can you please summarize the latest from the experiments suggested by Vaibhav?

Regards

Karan

Sorry about the late reply.  

E1:
Leverage QSPI reset from SDK 10.0, I checked our schematic, we didn't have the reset pin from the flash part to a GPIO. What should we do here to issue a QSPI boot reset? 

void flashFixUpQspiBoot(void)
{
uint32_t gpiobaseAddr, pinnum;

/* Get address after translation translate */
gpiobaseAddr = (uint32_t) AddrTranslateP_getLocalAddr(CONFIG_GPIO0_BASE_ADDR);

pinnum = CONFIG_GPIO0_PIN;

/* Drive the GPIO Pin low to assert the reset signal */
GPIO_pinWriteLow(gpiobaseAddr, pinnum);
ClockP_usleep(DELAY_SEC);

/* Drive the GPIO Pin high to deassert the reset signal */
GPIO_pinWriteHigh(gpiobaseAddr, pinnum);
ClockP_usleep(DELAY_SEC);
}

E2:

Could not work on the E1 experiment, given the reason above. Did add ospi_flash_io test in the SBL_UART_UNIFLASH project, and it failed with primary UART boot, which was discussed on another thread.  https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1408607/am2432-what-is-the-difference-between-primary-uart-boot-mode-and-backup-uart-boot-mode/5415928#5415928 

E3:

E2 failed as above. 

For the primary UART boot OSPI issue, we can leave it to another thread. 

For USB related issue here, we have two open questions: 
1) Could not issue QSPI reset, what is the suggestion from TI?
2) Failed with DMA, but passed without DMA with USB boot.  

Thanks, 
Hong 

Hello Hong,

We are following up actively on the other UART bootmode query, lets get that to closure before coming here.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1408607/am2432-what-is-the-difference-between-primary-uart-boot-mode-and-backup-uart-boot-mode

Regards,

Vaibhav

Hi Hong,

I haven't looked at the dfu-util or libusb to increase the timeout but I have found the SBL_DFU_UNIFLASH itself could tell the host to wait for a certain time after the download is complete.

The following patch configures the timeout of 10s

diff --git a/examples/drivers/boot/sbl_dfu_uniflash/am243x-evm/r5fss0-0_nortos/main.c b/examples/drivers/boot/sbl_dfu_uniflash/am243x-evm/r5fss0-0_nortos/main.c
index de2805c..f6c2b5e 100644
--- a/examples/drivers/boot/sbl_dfu_uniflash/am243x-evm/r5fss0-0_nortos/main.c
+++ b/examples/drivers/boot/sbl_dfu_uniflash/am243x-evm/r5fss0-0_nortos/main.c
@@ -131,6 +131,11 @@ uint32_t tud_dfu_get_timeout_cb(uint8_t alt, uint8_t state)
 	  /* as of now we support only flash memory */ 
 	  return 1 ; 
   }
+
+    if(state == DFU_MANIFEST) {
+        return 10000;
+    }
+
   return 0;
 }
 

The issue with this is the host will completely block itself for that period even if the device is done flashing and ready to receive another image. Only after the timeout is expired, the host tries to get the status for the device.

You may try this out just for testing purpose.

As for the solution, I think you should initialize the flash in the maximum mode possible to decrease the flashing time.

Regards,

Prashant