After Zephyr instalation, USB port isn´t being recognized by Windows as a COM port

[Claudio Rosa]

Good morning,

I am developing my Zephyr solution with a Supported board RAK4631 in a RAKWireless solution called Wisblock.  This is a kind of building blocks called Wisblock for Embeded Systems:

1. RAK4631: a combo with Nordic nRF52840 connected with a Semtech LoRa Radio SX1262
2. RAK19007: RAK19007 is a WisBlock Base Board 2nd Gen that connects WisBlock Core, WisBlock IO, and WisBlock Module

When the RAK4631 was a Bootloader and Softdevice to support Arduino BSP, the USB port was being reconized without problems.  But when I flashed (VSCode/nRF connect SDK for VSCODE Extension Pack), the Windows stop to recognize the USB port as a COM port, but J-Link is being recognized.

As you can see in the RAK4631 Schematic Diagram:

1. Pin 1: VBUS
2. Pin2: USB -
3. Pin3: USB +

From RAK19007 manual:

"For convenience, there is a Type-C USB connector that is connected directly to WisBlock Core MCU’s USB port (if supported) or to a USB-UART converter depending on the WisBlock Core. It can be used for uploading firmware or serial communication. The USB-C connector is also used as a battery charging port"

Type-C USB port

The Type-C USB connector is compliant with the USB 2.0 specification. This USB interface directly communicates with the connected WisBlock Core module. It is also used as a charging input port for the battery. Here are some of the advantages of the Type-C USB connector:

• Smaller and reversible connector shape
• Port can be input or output
• Fast battery charging

Could you help me?

Regards,

Claudio

RAK4631 Schematic Diagram

Windows COM port list.

RAK4631 mounted in a RAK19007

RAK4631

RAK19007

RAK19007 Block Diagram

Power supply diagram

[Edvin]

Hello,

I am not familiar with this device, but it looks like it doesn't have a programmer/debugger, but a preflashed bootloader, is that correct?

When you plug in a device, the nRF Connect VS Code plugin looks for debuggers or familiar bootloaders. If your device had a familiar bootloader, and it is either removed (erased) or it has an application that doesn't know of any bootloader, then it will not be communicated over USB, and VS Code doesn't know what to do with it. 

You say that it was recognized before. What did you program to it when it stopped? And how did you program it? Via the bootloader or using an external debugger?

Best regards,

Edvin

[Claudio Rosa]

Answering your questions:

1. It was being recognized with the RAKWireless bootloader: a example how the RAKWireless booloaders is flashed: "nrfutil.exe dfu serial -pkg rak4631_factory_bootloader.zip -p COM5" ,  it stopped to recognized after  MCUBoot+Zephyr(Application) 
2. I did with nrf connect for VSCode, with "west flash" and "CONFIG_BOOTLOADER_MCUBOOT=y" in the prj.conf.
3. Using J-Link
4. Below you are seeing the flash map via Programmer (nRF connect for Desktop), the build process with "west build" and the flashing process with "west flash"
5. 
6. 
7. 

As I am learning Zephyr, I did in two ways:

1. I did with "west" (in the nRF connect for VSCode) with prj.conf with "CONFIG_BOOTLOADER_MCUBOOT=y" and "west" flashed the "merged.hex" with "erase all".  In the nRF connect SDK for Desktop, I saw the two partitions:
   1. MCUBoot
   2. Application - Zephyr
2. I did with "west" the flash process with only Application - Zephyr

If I understood, when I did the "erase all", The old BootLoader  and Softdevice(Arduino BSP) from RAKWireless were deleted.

Please correct if I am wrong, but now I think that I must flash the MCUBoot, as a bootloader, to be able to get access to USB port again.  Am I correct?

 

Regards,

 

Claudio

[Edvin]

Claudio Rosa said:

I did with nrf connect for VSCode, with "west flash" and "CONFIG_BOOTLOADER_MCUBOOT=y" in the prj.conf.

This is a different bootloader (the previous one was using an nRF5 SDK bootloader, since it used nrfutil to flash). I am not familiar with how this particular bootloader worked. If it was intended to be programmed with arduino IDE, then it must have enabled this bootloader from all the applications it flashed. Bootloaders are complex. If it had a serial/USB bootloader, then either:

1: the application must have been aware of it, exposing some information about it via USB,

or 2: you needed to hold a button while resetting the device to tell it to enter DFU mode. 

If 1: If you programmed an application that is not aware of that particular bootloader, it will not expose this information via USB, and it also doesn't have a way to tell the bootloader to start in DFU mode.

if 2: You may still have the bootloader, unless you erased it with a debugger. 

Either way, if the bootloader is gone (I can't tell from the picture, but if you flashed it with a debugger, it probably is gone), then you either need to get hold of the old bootloader, and re-flash it. Alternatively, you need to use the programmer from now on (to be fair, this gives you much more possibilities, such as debugging.)

Claudio Rosa said:

Please correct if I am wrong, but now I think that I must flash the MCUBoot, as a bootloader, to be able to get access to USB port again.  Am I correct?

Yes, you do. But it is not as simple as "CONFIG_BOOTLOADER_MCUBOOT=y". This adds the bootloader, but your application will then be the one responsible for transferring the new image into the open application slot. 

If you want the old functionality back, you need to ask the producers of the module if they can send you the bootloader (or perhaps it is available somewhere online). 

If you want to look into building your own bootloader, you can do so, but as of now, it will still not show up in VS Code (not yet supported). But then you can use a tool called mcumgr to perform DFU.

Best regards,

Edvin

[Claudio Rosa]

For of all thank for all informations!

I am begining to work a new MCUBoot with mcumgr and I will give news as soon as possible.

Have a nice weekend.

Regards,

Claudio