Problem with pico-examples/i2c/bus_scan/bus_scan.c ??

[ibrahimqazi]

Hello all when I compile the code to scan devices on bus. Copy the uf2 file Pico, Pico disappears but it's COM port is not detected by neither computer device manager nor serial port utility. During compilation I also observe this warnning:

bus_scan\bus_scan.c:38:2: warning: #warning i2c/bus_scan example requires a board with I2C pins [-Wcpp]
   38 | #warning i2c/bus_scan example requires a board with I2C pins

These are the contents of my CMakeLists.txt file:

add_executable(i2c_bus_scan
        bus_scan.c
        )

# Pull in our (to be renamed) simple get you started dependencies
target_link_libraries(i2c_bus_scan pico_stdlib hardware_i2c)

# enable usb output, disable uart output
pico_enable_stdio_usb(i2c_bus_scan 1)
pico_enable_stdio_uart(i2c_bus_scan 0)

# create map/bin/hex file etc.
pico_add_extra_outputs(i2c_bus_scan)

# add url via pico_set_program_url
example_auto_set_url(i2c_bus_scan)

My computer gives me this message: USB Device not Recognized.

But when I burn Hello World program, it works and prints text to Serial port or USB without any problem.

Can anybody suggest me what should I do? Do I need to make any changes in bus_scan.c file? I reckon no changes are required.

[lurch]

bus_scan\bus_scan.c:38:2: warning: #warning i2c/bus_scan example requires a board with I2C pins [-Wcpp]

Are your pico-sdk and pico-examples repos both up to date?

EDIT: Also, if you're printing the bus_scan results to the USB stdio, then the bus_scan code might have finished running before the USB-enumeration process on your PC has finished?

[fivdi]

EDIT: Also, if you're printing the bus_scan results to the USB stdio, then the bus_scan code might have finished running before the USB-enumeration process on your PC has finished?

To resolve this issue, call tud_cdc_connected as describrd here.

[ibrahimqazi]

EDIT: Also, if you're printing the bus_scan results to the USB stdio, then the bus_scan code might have finished running before the USB-enumeration process on your PC has finished?

To resolve this issue, call tud_cdc_connected as describrd here.

Thank you its prints the scanned results, but now I observe another issue. After the result is printed, serial port tools hangs and no response. do you have any idea please? Another point, even I close the serial port using Task Manager, the port still cant be used once I switch off the controller completely, and then re run the software but as usual the same issue of halting occurs.

[lurch]

Can you clarify what you mean by "serial port tools hangs"?

then re run the software

Note that Windows sometimes changes which COM port gets assigned to a USB CDC (serial-port) device when you unplug and replug.

[ibrahimqazi]

Can you clarify what you mean by "serial port tools hangs"?

then re run the software

Note that Windows sometimes changes which COM port gets assigned to a USB CDC (serial-port) device when you unplug and replug.

I am using serial port utility to read IIC bus scan results. But when I open the COM port I get the scanned result but my serial port utility software halts and no response. Even I close the tool using windows Task Manager but when I rerun the tool I cant communicate with COM port. Then I turn off and on Pico and I am able to connect with Pico's COM port. So I think that this bus_scan script causes some problem.

Note that Windows sometimes changes which COM port gets assigned to a USB CDC (serial-port) device when you unplug and replug.

I assigned permanent COM port number in the device manager so it's always the same. This should not be the problem.

[lurch]

when I rerun the tool I cant communicate with COM port. Then I turn off and on Pico and I am able to connect with Pico's COM port.

I think that's expected behaviour? When the bus_scan program finishes, the program exits (unlike the hello_world example, the bus_scan program doesn't run in an infinite loop), and so there's not actually any code running on the Pico to send / receive data from the COM port. Can you describe what you expected to happen?

[fivdi]

when I rerun the tool I cant communicate with COM port. Then I turn off and on Pico and I am able to connect with Pico's COM port.

I think that's expected behaviour? When the bus_scan program finishes, the program exits (unlike the hello_world example, the bus_scan program doesn't run in an infinite loop), and so there's not actually any code running on the Pico to send / receive data from the COM port.

Yes, when main is allowed to return, as is the case here, the USB connection will no longer exist. Typically, in a normal program main will run forever and never return. You may be able to achieve what you want by preventing main from returning, for example by adding an infinite loop at the end of main, something like this:

    while (true);

[kriskeillor]

I have the same issue - the Pico USB device not being recognized/COM port not opening - when I flash it with bus_scan, CMakeLists.txt modified to enable the USB and disable UART with the same code as in hello_usb. Narrow_io_write with usb enabled, and some programs I've written myself (but not all), also cause this issue. Which programs fail to register on USB seems random, but it is consistent.

No notable build warnings or errors (but I can post the full output if it would help). Using cmake and ninja.

The program seems to flash correctly. I'm using a Cytron Maker Pi Pico, and when I flash the Pico with bus_scan, the GP0, GP4, and GP5 LEDs on the maker board light up. I think that's expected.

From reading the linked forum thread, it seems like using a USB-Serial convertor could be the best solution - simply bypassing this issue with USB.

edit: Are there any serial-type cables that can plug into the Pico's mini USB port and a computer's USB port? In other words, basically a USB cable that acts like a serial cable..?

[lurch]

Which programs fail to register on USB seems random, but it is consistent.

As @fivdi explains above, it probably depends on whether the program is written to run in an infinite-loop, or whether it just prints-and-then-exits (at which point the USB serial port stops existing). Many of the example programs use the print-and-then-exit strategy because we were using USB-Serial converters during development (because they make debugging much easier).

edit: Are there any serial-type cables that can plug into the Pico's mini USB port and a computer's USB port? In other words, basically a USB cable that acts like a serial cable..?

No, that's not a thing.

From reading the linked forum thread, it seems like using a USB-Serial convertor could be the best solution - simply bypassing this issue with USB.

Yup, see e.g. section "9.2.5. Flashing and Running "Hello World"" in the Pico getting started guide.

[kriskeillor]

Thanks so much for your quick reply @lurch.

I purchased a DSD Tech SH-U095C USB to TTL UART converter cable, which uses the FTDI chip. It seems like the most versatile adapter that could serve in future projects, as well. The pinout is not super compatible with the Cytron Maker, but it works. Anyways, I got the output of bus_scan and narrow_io_write to be visible over serial.

By putting the narrow_io_write program inside an infinite loop, I was also able to see the output over USB.

Thanks again for the reply, and thank you for your explanation @fivdi.

[lurch]

Sounds like this can be closed now?