NanoVNA icon indicating copy to clipboard operation
NanoVNA copied to clipboard

WRONG PID after update

Open magellan-13016 opened this issue 4 years ago • 6 comments

Hi,

Before I update the firmware, when I did the lsusb command, I get this :

Bus 003 Device 036: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

After the update I get this :

Bus 003 Device 035: ID 0483:5740 STMicroelectronics STM32F407

So the PID changed from df11 to 5740.

I've tried to compile the DFU from source but I get the same result.

When I use the command dfu-util -d 0483:5740 -a 0 -s 0x08000000:leave -D ch.bin I get an error from dfu-util because the PID detected is not 5740 but df11.

I think there is problem with the firmware which is changing the good Product ID by a wrong one.

Could you confirm this problem ?

Many thanks, David.

magellan-13016 avatar Jun 29 '20 11:06 magellan-13016

Hi David, I'm not sure what you are arguing here, so excuse me if I get your point wrong and maybe that I'm writing a silly thing for you.

As per this VID:PID table for the STM products: https://www.the-sz.com/products/usbid/index.php?v=0483&p=&n=

DF11H is the Id for any STM device in DFU mode, while 5740H is the Id for the STM virtual COM Port.

This is the right way an upgrade procedure should work indeed. That is, once the upload to the MCU has ended, it is a good practice to switch away from the DFU mode, that to avoid any spurious command that could damage the flash content. In case you need it, the device should be re-entered into the DFU mode by the menu keys or by the HW jumper resetting the device.

Have a great day.

Massimo

Pmax65 avatar Jun 29 '20 13:06 Pmax65

Ok Massimo, you're right and I was completely wrong. After the device returned to normal mode, the ID have changed to 5740 and I thought it was because of the firmware update which could have modified it but it is just because in normal mode the ID is not the same.

I'm very confused... please close this stupid non issue and delete it. I'm a little ashamed to have posted it !

magellan-13016 avatar Jun 29 '20 14:06 magellan-13016

Hi David, You are absolutely wrong! You are not stupid, you are just human (like me of course) and you just learnt something new today about this devices. Stupid are those who believe to know everything and don't admit when they are wrong. Have a great day. Massimo

Pmax65 avatar Jun 29 '20 14:06 Pmax65

I don't believe that I've the rights to delete this thread, probably Edy555 (alias ttrftech, who own it) can do that. Or you can delete it yourself (if I remember well, I deleted one of mine for a mistake some time ago, so I'm almost sure that you can do it).

Anyways, I suggest you to leave this thread until edy555 doesn't decide to delete it, because I guess that there are other people who could learn something about this.

It was no way a stupid issue at all.

Pmax65 avatar Jun 29 '20 14:06 Pmax65

Many thanks Massimo... yes you're right, it certainly could help someone. Obviously, I didn't find anywhere a tutorial which explain that the Product ID is changing depending on whether the product is in DFU mode ot not. In fact, I found a tutorial that give this command line ti update a firmware under linux with DFU-UTIL :

dfu-util -d 0483:* -a 0 -s 0x08000000:leave -D firmware.bin

To avoid mistake, he use a wildcard and another person comment he could use the lsusb command to get the product ID.

And the author answered that is because some firmware have a wrong PID that can be change with DFU-UTIL and to avoid trouble he uses a wildcard.

So I followed his mind... the right way is to enter the device in DFU mode and after we can use the lsusb to get the correct ID and use it in the command instead of the wildcard.

Now I'm sure it will help someone to understand the good way to update the firmware.

Many thanks, David.

magellan-13016 avatar Jun 29 '20 19:06 magellan-13016

Nice to read bout that David.

In my opinion this is the right spirit of these threads.

Have great days.

Massimo

Pmax65 avatar Jun 29 '20 21:06 Pmax65