NUCLEO-L476RG Outboard DFU

[mark]

Hello, I am using a Nucleo-l476RG and having an issue communicating to the MCU when sending firmware using Outboard. I get the following error:
"status": "cannot update host: can't connect to stm32: timeout (00000000)",

Here is my setup:

Wiring MCU:

Wiring Outboard (I have verified)

• AUX3 → BOOT0
• AUX4 → RESET
• AUXRX → PA2
• AUXTX → PA3
• GND → GND

Code:
I am able to communicate and set the hub.set and card.dfu over I2C works. I am also sending up temp and voltage.

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "product", myProductID);
JAddStringToObject(req, "mode", "continuous");
JAddBoolToObject(req, "sync", true);
JAddStringToObject(req, "sn", "NUCLEO-L476RG");
bool success = NoteRequest(req);

J *req = NoteNewRequest("card.dfu");
JAddStringToObject(req, "name", "stm32");
JAddBoolToObject(req, "on", true);
success = NoteRequest(req);

ISSUE:
The firmware is downloaded but it fails to update:

2023-09-29 20:45:16: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-09-29 20:45:04: starting outboard DFU of stm32 firmware
2023-09-29 20:45:02: DFU host firmware ready: successfully downloaded
2023-09-29 20:43:50: DFU host firmware download started from blues_simple_ota_v2$20230924193043.binpack

I am not sure how to debug further. I did enable the Serial RX/TX in the STM32CubeIDE Pinout & Configuration, but I am not sure what to do in code, maybe this is the issue. I did review the SMT32 Outboard example.

Any help would be greatly appreciated.

Thank you.

[mat]

Hello @mark, welcome to the Blues community!

Thanks for detailing the problem.

If you haven’t already seen it, it would be a good idea to review this document (https://www.st.com/resource/en/user_manual/um1724-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf), in particular section 6.8 and the relevant description of the solder bridges in section 6.9.

In section 6.8:

By default, the USART2 communication between the target STM32 and ST-LINK MCU is enabled, in order to support virtual COM port. If the communication between the target STM32 PA2 (D1) or PA3 (D0) and shield or extension board is required, SB62 and SB63 must be ON, while SB13 and SB14 must be OFF.

In order for the USART2 to be mapped to pins PA2/PA3 as you want, you’ll need to make those modifications to the solder bridges.

Please try that, and let me know how it goes.
Thanks,
mat.

PS: By the way, you don’t need to enable UART2 in your program code. Outboard DFU works by communicating with the built-in bootloader, which enables UART2 itself, as well as handling the protocol for updating firmware.

[mark]

Thank you @mat! I will report back.

[mark]

Hi @mat, I thought I could get this working but I have not had any luck. I have switched to a NUCLEO-F041RE in order to turn on (solder) SB62/SB63 and turn off (unsolder) SB13/14. My NUCLEO L476RG had 4 sensors already wired with external LEDs so I decided to switch boards for easier soldering and a simple software configuration.

Configuration:

• NUCLEO-F041RE
• Unsoldered SB13/14 and verified using continuity test.
• Soldered SB62/63 and verified using continuity test.

Process:

1. Connected the board using:
   Wiring Outboard (I have verified)
   * AUX3 → BOOT0
   * AUX4 → RESET
   * AUXRX → PA2
   * AUXTX → PA3
   * GND → GND

   

2. Loaded the default program. This is the simple blink onboard LED every 500 MS and verified working.

3. Did not do any additional configuration in the STM32CubeIDE Pinout & Configuration screen per your note in the above response.

4. Did not add any note-c libraries to the default program since I will be using the Notecard USB Connect via the web browser.

5. Performed the following steps in the following order:

   5a.

   Request:
   {"req":"hub.set", "mode":"continuous", "sync":true}
   
   Response: 
   

   5b.

   Request:
   {"req":"card.dfu","name":"stm32","on":true}
   
   Response:
   {
    "mode": "aux",
    "name": "stm32"
   }
   

   5c.

   Request:
   { "req":"dfu.status"}
   
   Response:
   {
    "mode": "idle",
    "on": true
   }
   

   5d.

   In notehub, applied my firmware to the device.
   

   5e.

   Response:
   {"req":"dfu.status"}
   
   Request:
   {
    "status": "downloaded 43% (393216/899637)",
    "mode": "downloading",
    "on": true
   }
   

   5f.

   Response:
   {"req":"dfu.status"}
   
   Request:
   {
    "status": "successfully downloaded",
    "mode": "outboard-ready",
    "on": true,
    "body": {
     "crc32": 1739773050,
     "created": 1696694595,
     "info": {},
     "length": 899637,
     "md5": "eb4d023851a5192a04509426263d96b8",
     "modified": 1696694595,
     "name": "nucleof401re-5000$20231007160315.binpack",
     "notes": "5000 ms for blink from 500",
     "source": "nucleof401re-5000.binpack",
     "type": "firmware"
    }
   }
   

6. I am receiving the following errors in the notehub under Device/Summary

2023-10-09 23:05:35: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-09 23:05:23: starting outboard DFU of stm32 firmware
2023-10-09 23:05:21: DFU host firmware ready: successfully downloaded
2023-10-09 23:04:08: DFU host firmware download started from from nucleof401re-5000$20231007160315.binpack
2023-10-09 23:02:46: boot (hard reset [16292] [5.0] G:Gp:W~ M:Mp:W900 U:W0 R:Rp:W0 S:W15 T I:HN:get notification:XR5 W X Y)

[mat]

Hi @mark! Sorry to hear this isn’t working for you, and thanks for the detailed problem description. I’ve looked over what you wrote and don’t see anything amiss - the wiring looks correct as does your configuration steps.

I see that the Notecarrier’s DFU DIP switch is in the ON position. This is only required when you populate the Notecarrier-F with a Feather - it internally connects pins involved in Outboard DFU to the corresponding pins of the Feather. Please try sliding the DIP switch to the other side.

Thanks,
Mat.

[mark]

Hi @mat ,

I really wanted to solve this before I sent you a reply, but I still cannot get the notecard to communicate with the STM32.

I tried to disable the dfu on the Notecarrier F and that did not work. I then decided to use the Notecarrier A. You can see in the image below. I connected it to the Nucleo-F401RE the same way. I also disabled UART in the STM32CubeIDE so not to generate any software.

Sorry about all the different images combined together. I am limited to one upload to the forum. As you can see, I have:

• Enabled SB62/63
• Disabled TX/RX on the STM-LINK (not pretty but I did validate no connectivity between them)
• Disabled any code for USART
• Using pins PA_2 (TX) and PA_3 (RX) on the Nucleo board.

Observations and Questions:

• The firmware is completely download to the notecard.
• I noticed that after the software is downloaded, I do see the following. When this occurs, the STM32 LED2 stops blinking.

2023-10-21 21:19:18: boot (brown-out & hard reset [16292])

• My assumption is at this point; the notecard has successfully placed the STM32 into boot loader mode.
• Question: It seems like I am not able to communicate over USART on the STM32/NUCLEO. Are there any other settings on the notecard or STM32/NUCLEO that I can investigate or change? Baud rates, etc.?
• Question: Not sure how to ask this in a technical way. In the field, if there is a communication issue with the STM32 during an outboard firmware update, how long does it take for the notecard to tell the STM32 to reboot and continue as before? For me, when the notecard puts the STM32 into bootloader mode and there is a communication error, it does not come out of this mode right away. If I leave the device overnight, it will eventually go back to normal processing. If the device is in the field, what is the exception of how long after failure should the device return to its original state prior to the attempted outboard process?

FYI:
It was able to get the Notecarrier F and the Swan to update using the outboard process. This process is very smooth and for me, business changer. I want to be able to do the same for STM32/NUCLEO boards that I have and then move to a simplified board.

Thanks for your help,
Mark.

Combined Image

Full Log:

2023-10-21 21:24:43: DFU of host firmware aborted: cannot update host: can't connect to stm32: timeout (00000000)
2023-10-21 21:24:42: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:24:28: starting outboard DFU of stm32 firmware
2023-10-21 21:24:12: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:23:59: starting outboard DFU of stm32 firmware
2023-10-21 21:23:43: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:23:30: starting outboard DFU of stm32 firmware
2023-10-21 21:23:14: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:23:01: starting outboard DFU of stm32 firmware
2023-10-21 21:22:45: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:22:32: starting outboard DFU of stm32 firmware
2023-10-21 21:22:16: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:22:03: starting outboard DFU of stm32 firmware
2023-10-21 21:21:47: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:21:34: starting outboard DFU of stm32 firmware
2023-10-21 21:21:18: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:21:05: starting outboard DFU of stm32 firmware
2023-10-21 21:20:49: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:20:36: starting outboard DFU of stm32 firmware
2023-10-21 21:20:20: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:20:07: starting outboard DFU of stm32 firmware
2023-10-21 21:19:51: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:19:38: starting outboard DFU of stm32 firmware
2023-10-21 21:19:37: outboard DFU of stm32 firmware: can't connect to stm32: timeout (00000000)
2023-10-21 21:19:23: starting outboard DFU of stm32 firmware
2023-10-21 21:19:18: boot (brown-out & hard reset [16292])

[aba]

Hi Mark,

have you been able to solve the issue?

I have the same issue trying DFU from the notecard to an STML562:
“cannot update host: can’t connect to stm32: timeout (00000000)”

I measured the signals (see attached image). RST and BOOT0 signals seem to be OK. But I’am not sure about RX/TX. Should the NoteCard not send 0x7f to enter the bootloader?

Any help would be highly appreciated!

Best regards
Adrian