My guess is flashrom tries to read out the (JEDEC?) id and it is unknown or fails. The chip should be powered somehow, yes.
[ r:10 ] this just reads 10 bytes. However I think the chip, if it is typical SPI flash, probably needs a command (read/fast read/write/fast write/read JEDEC ID/etc) before it will do anything. r:10 just writes 10 * 0xff to the bus, the chip probably ignores it.
I'm not familiar with the uboot stuff or how the microcontroller in a camera loads from flash.
I need to verify from each datasheet proper input and output caps for the three different vregs when we confirm final part numbers (All MCPxxxx?)
we don't have input caps on the vregs that are more than 1cm from the main input cap (3.3v, 1.2v)
We need to consider our power budget. MCP1801 is good for 150ma only.
Currently we are using MCP1824 adjustable as the Vout. Confirmed in datasheet the test conditions are 4.7uf ceramic. As low as 1uF would work, but let's go with 4.7uF on input and output.
We are using MCP1801 for the 3.3volt and 1.2volt supplies. This is a 150ma LDO with enable. We really don't need the enable, but I like the SOT-23-5 package because it gives almost twice as much contact for thermal dissipation to the PCB. It will take some before we have a realistic power budget, but I believe we should target 200-250ma on both rails for development. The other issue is the display and LEDs, that's gonna eat up a bunch (60-80mA).
MCP1700 is cheap, no enable, 250mA. The three pin sot-23 package is limiting, but there is a SOT-89 between the SOT223 and SOT23 in size. The datasheet suggests 1uF on in and out, but more on input is possible. How about 1uF on output and 4.7uF on input to keep the BOM smaller?
VR1 to MCP1700-33 SOT-89? 4.7uF input capacitor, 1uF output cap (C28)
VR2 to MCP1700-12 SOT-89? 4.7uF input capacitor, 1uF output cap (C39)
Am I completely off the mark using Bus Pirate to check the SPI chip (see if i can write and read - checking if the chip is still "working"
Definitely the right track. I have not looked at the datasheet, but a lot of flash chips use the 0x03 read command. Can you verify that you can read it from the Bus Pirate terminal? something like [ 0x03 0 0 0 r:16] for the spi flash I'm messing with at the moment is [ (cs low), 0x03 (read command), 0 0 0 (set address to read from), r:16 (read 16 bytes), ] (cs high)
With my tests I can read and write, what I was trying to do is use flashrom then to flash a bootloader specifically uBoot
I assume you can write anything as long as you can tell it where to locate the data you're writing. I'm not familiar with flashrom at the moment.
Speed is tricky, some newer flash have minimum speeds. Generally I like to go slow because there's so much delay between bytes anyways that 2mhz vs 100khz isn't going to change much.
Quote
To do so, I used the Write-then-read function: 0x04 0x00 0x04 0x08 0x80 0x03 0x00 0x00 0x00
I'm not clear what this means. This is the result?
What chip is it? Are there setup and configuration commands, or address commands? Is your script handling that?
XC2C64A_VQ100.bsdl, bbv4.svf. these should be the right files. And you should be targeting interface 1, if I recall correctly (because the JTAG tools all use interface 0).
If this is v4, is there some kind of jumper or something that needs to be set for programming mode? That might be the one with the 44 pin CPLD.
I believe we need to split the protocol handing in the MCU into separate "compiling" and "result" functions, then we can start hooking up all the protocols.
This is a little test board that plugs into the Bus Pirate header. The LEDs show if the pin is high or low to make debugging easier. We also brought out Vout to measure, or to use an external Vref with the buffer.
The display datasheets are a mess. It's a long story that might make a good blog post some day. The displays connector is soldered to the PCB, it doesn't use a ZIF socket. Here's the display carrier board, we'll send this off soon.
We took out the hardware I2C option and warning really early on because it created a lot of chaos. There's probably a total of 100 Bus Pirates (it may have been the batch done for Hack a Day, predating Dangerous Prototypes, but I don't remember) out there with the bad silicon revision. HW I2C could be enabled with a compiler switch, at least in the past.
You would need to tap or bring out the RX and TX of the UART and then interface it at 115200 baud with settings 8/N/1.
The extra UART pins I assume were eliminated because we needed them for other functions. However, I'm not sure, but I believe the programming pins (ICSP) pins are PPS pins, so you could technically update the firmware to assign the UART to those pins instead of the FTDI chip.
I got datasheets (attached) from both of the 2inch LCD manufacturers. They actually have the same pinout, the text in one was just really messed up. So we'll only need a single carrier board to test both displays.
We can probably use the proper footprint on the next revision and save a lot of space