LPC1768 USB bootloader binary firmware problems

[Frank2201]

Greetings

I have this weird situation with USB bootloader. Generally im really satisfied with it. But depends of computer, when i load the firmware the code wont start running. Maybe after third or fourth try (delete firmware binary & load new one) the code start running. But on some computers I dont have any problems. And of course the binary file is always the same. Does someone had similar situation and found a solution?

Best regards

Frank

[tlah]

Hi there!

I had problems with the LPC BL on new windows. It seams MS decided to change some caching of the files. This results in binary stream loading to MCU to have mixed the order of blocks. Now since BL FW operation base on this order, the result is that the transfered code is not written in correct way. You hav to know that Erasing Flash data happens when first block of Flash sector is received! I'll name this N+0000 in the later description.

It happens that you first got transfered some data on block in sector N+offset. Next you got block N+0000. This mix up erases data allready written to flash. So you have to fix this in BL FW by erasing code flash on the first block transfered. Nothing else is reliable.

There are some other issues with windows patches lately but this stays. Or you can use Windows 7

[Frank2201]

Thank you for your contribution about this.

I believe my problem lies elsewhere. I not sure with WIN11, but i mostly use BL on WIN10. In most cases there is no problems, only rare cases on some computers seems to flashing fail in first few tries.

I suspect buggy USB drivers or USB hardware on computer motherboard, who knows, because its rare to find a computer that have such issues.

Or maybe when you make binary firmware on development computer, some other computer read binary in different way.

Had problems with BL in some old computer with WIN10 but don't work anymore, so cant do detailed research what is the problem.

[tlah]

Hi there!

I had problems with the LPC BL on new windows. It seams MS decided to change some caching of the files. This results in binary stream loading to MCU to have mixed the order of blocks. Now since BL FW operation base on this order, the result is that the transfered code is not written in correct way. You hav to know that Erasing Flash data happens when first block of Flash sector is received! I'll name this N+0000 in the later description.

It happens that you first got transfered some data on block in sector N+offset. Next you got block N+0000. This mix up erases data allready written to flash. So you have to fix this in BL FW by erasing code flash on the first block transfered. Nothing else is reliable.

There are some other issues with windows patches lately but this stays. Or you can use Windows 7

[Alice_Yang]

Hello @Frank2201 

How about change to other USB ports of PC and USB line?

BR

Alice

[Frank2201]

Hello @Alice_Yang

Thank you for your reply.

Yes, they tried, they even tried on multiple computers.

I send the binary with new software version to SMT assembler via email. There are no problems at my side. Tried multiple times to load but didnt come across with the problem. At assembler side, they are problems, they even tried on multiple computers. Changed USB cables too. The code maybe start running on third try. I asked them to send me binary file back to me via email. But when i tried this binary at my side i didnt get any problems. Code started always after first try. We and they have OS win10.

The more weirder is, that older binary file (older software version) is working without any issues at assembler side. So, im really without any idea why.

[Alice_Yang]

Hello @Frank2201 

1) Do you use the same custom board? 

2) I guess you meaning the  LPC1700 secondary USB bootloader

If yes, what about the state of p1.20 on assembler's side? Pay attention:

BR

Alice

[Frank2201]

Im 100% sure there is no hardware issue. Yes, we are using LPC1700 secondary USB bootloader

Assemblers side:

The new firmware (binary file) starts running after few tries - same hardware.

The old firmware (binary file) starts running after first try- same hardware.

Our side:

New and old firmware (binary file) works after first try. Executed multiple times just to be sure if the problem pop up randomly. But i eliminated this possibility too.

Best regards

[Alice_Yang]

Hello @Frank2201 

1)You and Assemblers use same image, same hardware, while the result not the same, it is strange. 

Does Assemblers only have one board, or lost of boards? How about test on other same boards?

2) " they even tried on multiple computers. Changed USB cables too."

->> All the PCs on their side have the same issue? 

BR

Alice

[Frank2201]

1. Yes. assemblers have multiple board and have same issues on all boards. These board come to us and then we load new firmware to it without problems. Assembler dont load new firmware because they need too much precious time with retrying. So, we load new firmware at our side in this moment.

2. Yeah, they tried with multiple computers and have same issues.

I suspect there is something with computer side. USB drivers, windows system, motherboard, who knows. Its hard because i dont have any problems on my side. If I had such computer with such issues then i could analyze the problem.

[Alice_Yang]

Hello @Frank2201 

Sorry I also can't reproduce customer's issue, how about update a simple image? For example just a led demo image?

BR

Alice

[Frank2201 · Accepted solution]

Hello @Alice_Yang 

Thank you for your help. It seems this is some unique problem and I cant do tests/diagnostics myself because i dont have issue on my side. Unfortunately, I cant burden Assembler team with these tests, they are occupied with other work. For now, the Assembler will load old firmware and we will load new firmware. Unfortunately this is satisfied solution for us now.

Will try to find out myself if i can find the solution but it will take some time.

Best regards