Original post is preserved below for you guys to have a laugh. I've found the issue. For best comic effect read the original post first, and then the solution. If you just want to help and are not in for a laugh at my expense, you can stop reading now. ![:-)]( "Smile")
---------------------------------------
Pretty sure I'm not the first. (I see people with similar problems in the forum overview).
I'm not a newbie. I've designed dozens of boards with RP2040, I've built hundreds of them. Not one "structural" problem with the RP2040. Sure, I've had soldering issues, and problems with the application side of the boards, (Most recently I've put resistors "in line" of the connection to the IO of the board, instead of the pullup that the application required. Duh! New boards are in transit....)
Most recen "bring-up" of a board landed with all boards not being able to program the flash. Different flash chip: same story.
Then we transplanted a "working flash" from another board, and.. .Voila! it boots. Maybe the new board can't program the chips? Reboot, program new version of the program and... works!
Something with the chip? Possibly. I seem that I have Winbond 25Q16JVSIQ as the non-working ones, and 25Q32FVSIG as the working ones. The only difference I've been able to find is that one is rated for 133MHz and the other is not.
I could understand it if the faster chip works, and the slower one doesn't because the pico might have the faster one and the second stage bootloader from the pico enables the faster mode... The working one is the slower 104MHz one.
I'll try a few more things, like soldering the not-working chip onto the previously working board. But in the meantime: Anybody have any ideas? Does anybody know of any more differences between the FV vs JV versions of the winbond chip? Manually diffing the datasheets so far hasn't turned up anything obvious. My first conjecture was that the not-working one might be "not for 3.3V", but that hypothesis proved wrong. Any other hypotheses?
-----------------------------------
Ehh..... The RP2040 program that was on my "automatically program any RP2050 in bootloader mode" system was of a family of boards that happens to have one family member that is sufficiently close to this board that I'm going to use that software. I didn't realize this when first "check if it boots and accepts software", but by now I have. Anyway. booloader, program reboot... bootloader and repeat.... Well.... That family has a fancy communication system and some boards may need a remote upgrade. So I've made a bootloader at 0x100000 and the "real program" starts a bit later. So my build system builds the main program to start later and generates a normal UF2. Once the bootloader is installed it can boot the "normal program" that's further along in the flash,. But as long as my bootloader isn't loaded, the ROM bootloader will say: no second stage boot sector, so perform USB boot sequence... Aargh!
I'm working on a program to combine two UF2 files. Everybody merges the BIN files converts to ELF and then outputs the UF2 of the combined stuff. I think writing the UF2 combiner should be easier than learning how to do that.... So far I've been proven wrong: it didnt' work first try. I'll publish once I get it working.
---------------------------------------
Pretty sure I'm not the first. (I see people with similar problems in the forum overview).
I'm not a newbie. I've designed dozens of boards with RP2040, I've built hundreds of them. Not one "structural" problem with the RP2040. Sure, I've had soldering issues, and problems with the application side of the boards, (Most recently I've put resistors "in line" of the connection to the IO of the board, instead of the pullup that the application required. Duh! New boards are in transit....)
Most recen "bring-up" of a board landed with all boards not being able to program the flash. Different flash chip: same story.
Then we transplanted a "working flash" from another board, and.. .Voila! it boots. Maybe the new board can't program the chips? Reboot, program new version of the program and... works!
Something with the chip? Possibly. I seem that I have Winbond 25Q16JVSIQ as the non-working ones, and 25Q32FVSIG as the working ones. The only difference I've been able to find is that one is rated for 133MHz and the other is not.
I could understand it if the faster chip works, and the slower one doesn't because the pico might have the faster one and the second stage bootloader from the pico enables the faster mode... The working one is the slower 104MHz one.
I'll try a few more things, like soldering the not-working chip onto the previously working board. But in the meantime: Anybody have any ideas? Does anybody know of any more differences between the FV vs JV versions of the winbond chip? Manually diffing the datasheets so far hasn't turned up anything obvious. My first conjecture was that the not-working one might be "not for 3.3V", but that hypothesis proved wrong. Any other hypotheses?
-----------------------------------
Ehh..... The RP2040 program that was on my "automatically program any RP2050 in bootloader mode" system was of a family of boards that happens to have one family member that is sufficiently close to this board that I'm going to use that software. I didn't realize this when first "check if it boots and accepts software", but by now I have. Anyway. booloader, program reboot... bootloader and repeat.... Well.... That family has a fancy communication system and some boards may need a remote upgrade. So I've made a bootloader at 0x100000 and the "real program" starts a bit later. So my build system builds the main program to start later and generates a normal UF2. Once the bootloader is installed it can boot the "normal program" that's further along in the flash,. But as long as my bootloader isn't loaded, the ROM bootloader will say: no second stage boot sector, so perform USB boot sequence... Aargh!
I'm working on a program to combine two UF2 files. Everybody merges the BIN files converts to ELF and then outputs the UF2 of the combined stuff. I think writing the UF2 combiner should be easier than learning how to do that.... So far I've been proven wrong: it didnt' work first try. I'll publish once I get it working.
Statistics: Posted by rew — Tue Feb 13, 2024 11:50 am