I’m new to Generator, I’m down in the Brattleboro area. If this post is in the wrong forum, please let me know.
I have two open source chip programmers I’m trying to make work. I was flashing LPC chips fine with either one until the programmers just stopped recognising my chips. I’ve verified the chips still work in the mainboard I’m flashing them for.
One is based on a teensy, the other an arduino uno which is completely open hardware I believe. Unfortunately, I’m not very familiar with electronics troubleshooting, and don’t have the right tools to diagnose this properly.
Does anyone have any advice for me on this?
Do you have any more information about the teensy and uno programmers that you’re using? Are you interfacing via JTAG, SWD, or something else? Also, what software stack are you using to program the chips?
I’ve never worked with the NXP LPC series of microcontrollers, but have had good luck with using the OpenOCD project on the Raspberry Pi as a method of programming other ARM Cortex based chips (STM32, ATSAMD) via the GPIO headers.
Leif, thanks for your reply.
The first programmer I was using is described at Teensy 3.1 SPI + LPC/FWH Flasher - flashrom .
Now I have set up Serprog/Arduino flasher - flashrom .
The programmers write to 32 pin flash chips. I believe the 3V clocked LPC protocol has 4 pins for writing or reading 4 bits of data at once.
I breadboarded the layouts, rather than doing the surface mount soldering the pages recommend. Although I’m relatively young, my hands shake and vision is poor, so smd soldering can be hard for me.
Both of these programmers worked fine, then stopped recognizing the chips. I’ve checked the breadboard connections, reflashed the mcus, tried different host systems and different flash chips. I’m not sure what to try next.
I looked into openocd: this would be for debugging the arduino or teensy, I think?
What model of LPC chip are you targeting, specifically? Is flashboot your primary programming tool? What kinds of errors are being thrown when you attempt to program the chips unsuccessfully? Generic “chip not found” kind of errors, or something more arcane?
OpenOCD is primarily used as a method to facilitate chip debug interfaces of varying types, but can also be used to write directly to the flash memory of a microcontroller if it has JTAG/SWD compatibility. I don’t think it supports the LPC or FWH interfaces directly, so not a good solution in this case, my apologies.
There’s nothing more frustrating than a working jig suddenly failing without reason. It’s almost enough to justify paying the extortionate prices for the official programmer. Almost. =8)
I think the target model is SST49LF080A , and I’m using the serprog interface of flashrom.
The error message is “No EEPROM/flash device found.” This happens after it fails to probe for a chip model. I believe my chips usually probe as Winbond W39V080A .
[edit: I guess I need to look at my flash chips and logs more carefully as those appear to be distinct chips. All my chips work the same in my mainboard and flashed the same before my flashers failed.]
I can pass verbose flags to flashrom and it will show the reads and writes being passed via the programmer. When the probe fails, it sends some configuration writes and then reads two bytes from fixed addresses and compares them with constants associated with the chip model.
The two bytes are now always reading as 0xFF each. I think this might mean the data pins are always low, not sure.
Note: I haven’t found an official programmer for these chips. [edit: although I just tried adding the model number as a search term and it turns out there are possible ones I haven’t looked into, like a universal programmer]
There also seem to be a bunch of “BIOS Programmer” options floating around with LPC/FWH compatibility, but none seem to float to the top as a definitive standard.
Maybe rebuild on a different breadboard as a last resort before a new purchase? Those things fail all the time. All it takes is one intermittent connection to ruin your day.
A long shot idea: I was looking at the arduino based programmer schematic and noticed that there are no power decoupling caps on the VDD pins (25,32) of the PLCC socket. That can sometimes cause intermittent hardware behavior. Is there any change in behavior if you add 100nF caps between each pin and ground?
Thank you so much for your inspiring help.
I added the caps. There are two other VDD pins, too. It still failed.
I ended up adding a pin testing functionality to the firmware. When I opened the source I found it had an interactive mode for debugging, already, that made this easy to add.
I found via testing pin voltage levels while changing them, that when rewiring it after dropping it, I had miswired and then mislabeled one of the connections.
I would also have found this if I had rebreadboarded it as you recommended. I can find software development easier than wiring, myself.
Thank you. It is working for now.
At some point I would like to figure out things like oscilloscopes and logic analyzers to hunt down issues like this in a reliable and general manner.