flash.sh hangs "after flashing" the board about docker

[ipa-hsd]

Worked! Had to changed the cable, now dmesg shows:

[354712.503473] usb 2-1: new full-speed USB device number 80 using xhci_hcd
[354712.653021] usb 2-1: New USB device found, idVendor=0525, idProduct=a4a7, bcdDevice= 1.01
[354712.653027] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[354712.653030] usb 2-1: Product: CDC/ACM Serial
[354712.653033] usb 2-1: Manufacturer: NuttX
[354712.653035] usb 2-1: SerialNumber: 0
[354712.655461] cdc_acm 2-1:1.0: ttyACM1: USB ACM device

So with ttyACM1 profile, I get the nsh prompt.
Thanks @iluetkeb and @Viplav04 !!

[ipa-hsd]

If I run openocd with -d 1 option I get the following output:

Debug: 20057 14557 hla_target.c:431 adapter_debug_entry(): entered debug state in core mode: Thread at PC 0x20000046, target->state: halted
Debug: 20058 14557 target.c:1517 target_call_event_callbacks(): target event 0 (gdb-halt)
Debug: 20059 14557 target.c:1517 target_call_event_callbacks(): target event 1 (halted)
User : 20060 14557 armv7m.c:556 armv7m_arch_state(): target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000046 msp: 0x20006f94
Debug: 20061 14557 hla_target.c:470 adapter_poll(): halted: PC: 0x20000046
Debug: 20062 14557 hla_target.c:58 adapter_load_core_reg_u32(): adapter_load_core_reg_u32
Debug: 20063 14557 hla_target.c:73 adapter_load_core_reg_u32(): load from core reg 15  value 0x20000046
Debug: 20064 14557 armv7m.c:510 armv7m_wait_algorithm(): restoring register xPSR with value 0x01000000
Debug: 20065 14557 armv7m.c:510 armv7m_wait_algorithm(): restoring register pc with value 0x08000188
Debug: 20066 14557 armv7m.c:510 armv7m_wait_algorithm(): restoring register r8 with value 0x00000000
Debug: 20067 14557 armv7m.c:510 armv7m_wait_algorithm(): restoring register r7 with value 0x00000000
Debug: 20068 14557 armv7m.c:510 armv7m_wait_algorithm(): restoring register r4 with value 0x00000000
Debug: 20069 14557 armv7m.c:510 armv7m_wait_algorithm(): restoring register r2 with value 0x00000000
Debug: 20070 14557 armv7m.c:510 armv7m_wait_algorithm(): restoring register r1 with value 0x00000000
Debug: 20071 14557 hla_target.c:750 adapter_read_memory(): adapter_read_memory 0x20000050 4 1
Debug: 20072 14557 target.c:2240 target_read_u32(): address: 0x20000050, value: 0x20000154
Debug: 20073 14557 target.c:1846 target_free_working_area_restore(): freed 16384 bytes of working area at address 0x2000004c
Debug: 20074 14557 target.c:1640 print_wa_layout():  * 0x20000000-0x2000004b (76 bytes)
Debug: 20075 14557 target.c:1640 print_wa_layout():    0x2000004c-0x20007fff (32692 bytes)
Debug: 20076 14557 target.c:1846 target_free_working_area_restore(): freed 76 bytes of working area at address 0x20000000
Debug: 20077 14557 target.c:1640 print_wa_layout():    0x20000000-0x20007fff (32768 bytes)
Debug: 20078 14557 target.c:2328 target_write_u32(): address: 0x40023c10, value: 0x80000000
Debug: 20079 14557 hla_target.c:764 adapter_write_memory(): adapter_write_memory 0x40023c10 4 1
User : 20080 14558 command.c:544 command_print(): wrote 524288 bytes from file nuttx.bin in 14.498052s (35.315 KiB/s)
Debug: 20081 14558 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_init
Debug: 20082 14558 command.c:143 script_debug(): command - init ocd_init
Debug: 20083 14558 log.c:431 keep_alive(): keep_alive() was not invoked in the 1000ms timelimit (5533). This may cause trouble with GDB connections.

[iluetkeb]

It's normal that OpenOCD does not terminate. After flashing it stays open as a debugging server. Simply interrupt it using Ctrl-C.

[ipa-hsd]

I was wondering if the flashing did not complete properly because the nuttshell doesn't show up in minicom:

$ sudo minicom -D /dev/ttyACM0

I see that the board is using uros configuration in the docker image. Does this use USB OTG by default or the UART? I tried using FTDI's FT232 as well.

[ipa-hsd]

Sorry, I just saw that the image uses serial transport. So I tried with serial cable and

sudo minicom -D /dev/ttyUSB0

Still the nsh prompt doesn't show up.

[iluetkeb]

Try pressing "Enter" three times. See http://nuttx.org/Documentation/NuttShell.html for reasons...

If that doesn't work, make sure you have 115200 baud, 8N1 and no hardware flow control.

[iluetkeb]

One more thing: After flashing, the board is stopped which you can also detect by the fact that the green LED is off. You need to press the reset button (next to the red LED). After that, you can try NSH.

[ipa-hsd]

I should have mentioned that in my previous comment: I have checked that the baud-rate is 115200, 8N1 and no hardware flow control.
Also, I reset the board and I see that the green LED is on.

[Viplav04]

@ipa-hsd
this should help https://youtu.be/rgZJPZh_po8
type dmesg in terminal to check which device is assigned to the board

[ipa-hsd]

@Viplav04 I have seen that video, but that would be helpful if I want to use the USB instead of serial right? Currently the image is configured to use serial. And I am wondering why doesn't it work.
I can see both ST-Link and FTDI devices being detected:

[353250.429375] usb 2-2: new full-speed USB device number 78 using xhci_hcd
[353250.587042] usb 2-2: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
[353250.587048] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[353250.587051] usb 2-2: Product: STM32 STLink
[353250.587054] usb 2-2: Manufacturer: STMicroelectronics
[353250.587056] usb 2-2: SerialNumber: Tÿr�w\xc2\x89PW"D�g
[353256.765364] usb 2-3.2: new full-speed USB device number 79 using xhci_hcd
[353256.884386] usb 2-3.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[353256.884392] usb 2-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[353256.884395] usb 2-3.2: Product: FT232R USB UART
[353256.884398] usb 2-3.2: Manufacturer: FTDI
[353256.884400] usb 2-3.2: SerialNumber: AO007WFQ
[353256.892823] ftdi_sio 2-3.2:1.0: FTDI USB Serial Device converter detected
[353256.892857] usb 2-3.2: Detected FT232RL
[353256.893450] usb 2-3.2: FTDI USB Serial Device converter now attached to ttyUSB0

A student has tried setting up the uros_ws on a system with ROS Crystal and it worked fine. Now I am trying to do the same with docker. Do I need to do something differently for docker?
Let it try connecting to the board with a "native" ROS crystal system to confirm if it is actually an issue with docker.

[Viplav04]

@ipa-hsd I didn't use it with the serial because i used the UART to connect with the agent. I set up everything manually as I tried with docker but it didn't work and I did not go into that.

Also as per the defconfig file for uros, which might be used in generating the docker image, (I'm not sure but i guess the repos accessed would be the same) has USB CDC/ACM profile enabled, so try to access nsh through ACM. Your dmesg command should show nuttx through a ACM profile.