1-WIRE> W
Power supply
Volts (0.80V-5.00V)
x to exit (3.30) >
3.30V requested, closest value: 3.30V
Maximum current (0mA-500mA), for none
x to exit (none) >
Current limit:Disabled
Power supply:Enabled
Vreg output: 3.3V, Vref/Vout pin: 3.2V, Current sense: 2.3mA
A slight change to power supply command W. At the current limit prompt hit enter for no limit, or a float value for a limit. X to exit. Here’s the view with no limit.
1-WIRE> W
Power supply
Volts (0.80V-5.00V)
x to exit (3.30) >
3.30V requested, closest value: 3.30V
Maximum current (0mA-500mA), for none
x to exit (none) > 100
100.0mA requested, closest value: 100.0mA
Power supply:Enabled
Vreg output: 3.3V, Vref/Vout pin: 3.3V, Current sense: 2.4mA
Here’s the view with a limit.
If the y/n prompt felt hacked on, it was. I didn’t add the override until late in REV 7 or so. I thought, what if someone finds a bug in the analog section? We better have a way to override it so the hardware is still usable
This should be a little more user friendly. I have a larger goal for a clean separation of menu prompts and parsing, but the PSU config was getting on my nerves.
Use previous settings?
SPI speed: 100 KHz
Data bits: 8
Clock polarity: Idle LOW
Clock phase: LEADING edge
y/n, x to exit (Y) > y
I did a bit of cleanup to the SPI “use previous settings” menu. It’s in the proper colors now. More importantly, I wrote a good parse and prompt function for the y/n menu. The default is yes, so you can blow through the config with enter, which is what I do 99% of the time. It also supports the x to exit option properly.
This isn’t pushed yet, i need to implement it everywhere.
What do you think about saving power, pullups and maybe AUX pin settings? Either as a full config for a mode, or maybe simpler like the PSU remembers the last settings and uses it as default?
SPI> (2)
Flash device manufacturer ID 0x85, type ID 0x60, capacity ID 0x15
SFDP V1.0, 1 parameter headers
Type Ver. Length Address
Table 0 JEDEC (0x00) 1.0 36B 0x9010000
JEDEC basic flash parameter table info:
MSB-LSB 3 2 1 0
[0001] 0xFF 0xF1 0x20 0xE5
[0002] 0x00 0xFF 0xFF 0xFF
[0003] 0x6B 0x08 0xEB 0x44
[0004] 0xBB 0x80 0x3B 0x08
[0005] 0xFF 0xFF 0xFF 0xEE
[0006] 0xFF 0x00 0xFF 0xFF
[0007] 0xFF 0x00 0xFF 0xFF
[0008] 0x52 0x0F 0x20 0x0C
[0009] 0x81 0x08 0xD8 0x10
4 KB Erase is supported throughout the device (instruction 0x20)
Write granularity is 64 bytes or larger
Flash status register is non-volatile
3-Byte only addressing
Capacity is 2097152 Bytes
Flash device supports 4KB block erase (instruction 0x20)
Flash device supports 32KB block erase (instruction 0x52)
Flash device supports 64KB block erase (instruction 0xD8)
Flash device supports 256B block erase (instruction 0x81)
Found a PUYA flash chip (2097152 bytes)
Flash device reset success
[SFUD]SPI_FLASH flash device initialized successfully.
Erase OK
Verify erase:
[-------------------c]
Erase verified
SPI>
Temporary SPI mode macro (2) tests the universal flash library erase function, with verification. It will erase a flash with no further warning, so use a chip with nothing on it.
The flash chip must have a SFDP table, which most modern 25Q chips do.
There’s a new progress indicator modeled after the Pacman progress indicator easter egg in a linux distribution.
I think the flash erase/program/read will be all wrapped up tomorrow, at least for chips with SFDP info. Then I’ll get it going in binary mode with desktop software.
SPI macro (2) now does erase, program, verify, and dump the contents to internal storage. This is still all a test, next I’ll implement it as a proper command with options.
The dump is saved as dump.bin for now, but a custom file name will be next.
Not a huge update, we had a lot of testing and assembly stuff to work on today. Bus Pirates will be shipping very soon.
Made some solid progress with a new command line argument parser. It will have to be implemented everywhere now, which is good because the old system was pretty ugly.
SPI> dump -r test.bin
Commands now accept - flag style arguments, with optional string or integer values (32 bits). For the flash command: -r(ead) {filename}, -w(rite) {filename}, -v(erify), -e(rase). There will be additional arguments to define the range, number of bytes, and to test erase/write/verify all or portion of a chip.
Flash device manufacturer ID 0x85, type ID 0x60, capacity ID 0x15
SFDP V1.0, 1 parameter headers
Type Ver. Length Address
Table 0 JEDEC (0x00) 1.0 36B 0x000030
JEDEC basic flash parameter table info:
MSB-LSB 3 2 1 0
[0001] 0xFF 0xF1 0x20 0xE5
[0002] 0x00 0xFF 0xFF 0xFF
[0003] 0x6B 0x08 0xEB 0x44
[0004] 0xBB 0x80 0x3B 0x08
[0005] 0xFF 0xFF 0xFF 0xEE
[0006] 0xFF 0x00 0xFF 0xFF
[0007] 0xFF 0x00 0xFF 0xFF
[0008] 0x52 0x0F 0x20 0x0C
[0009] 0x81 0x08 0xD8 0x10
4 KB Erase is supported throughout the device (instruction 0x20)
Write granularity is 64 bytes or larger
Flash status register is non-volatile
3-Byte only addressing
Capacity is 2097152 Bytes
Flash device supports 4KB block erase (instruction 0x20)
Flash device supports 32KB block erase (instruction 0x52)
Flash device supports 64KB block erase (instruction 0xD8)
Flash device supports 256B block erase (instruction 0x81)
Found a PUYA flash chip (2097152 bytes)
Flash device reset success
Dumping to test.bin…
[-------------------C]
Dump OK
It will take a day or so to get these changes into main. This is the first of three major reworkings that will happen hopefully by the end of this week.
HiZ> flash -h
usage:
flash [-i] [-p] [-e] [-w <file>] [-r <file>] [-v] [-t] [-h]
Initialize and probe: flash -i -p
Erase and program, with verify: flash -e -w example.bin -v
Read to file: flash -r example.bin
Test chip: flash -t
read, write and erase flash chips using SFDP info if available
-i Reset and initialize flash chip. Default if no options given.
-p Probe flash chip for ID and SFDP info
-e Erase flash chip
-w Write file to flash chip -w {file}
-r Read flash chip to file -r {file}
-v Verify flash chip erase or write
-t Erase and write full chip with dummy data, verify
flash command now shows a help menu with usage examples.
Other updates:
Complete rework of the command line arguments parsing system. It is much more flexible and user friendly, but not nearly as automated. This affected dozen of file and 100s of lines of code. There still some work to make the parsing functions less redundant.
flash command checks for buffer voltage and gives hints if none is found. This new function will be implemented everywhere.
flash command currently limited to SPI mode, but will be expanded to I2C and 1-wire memories.
flash write command is still in progress, it should be finished shortly.
After this I will do a major cleanup and re-org of SPI, and dive into the SPI binary mode. I also plan to address terminal resizing issues, and install the new saved mode setting prompt firmware wide.
Does "dump -w out.bin"write to the 1GB NAND flash storage? You might want to add a check to make sure it doesn’t overflow available space. I assume the binary/desktop mode sends the data to the flashrom program, which solves that problem.
Yes, that is exactly right. The storage system will give an error when full, but good point to check before dumping a large flash. I have 50MB of 2MB test files right now
I pushed a small update. Writes are working, and though undocumented, you can verify against a file by specifying a file name after -v.
It feels like the actions should be verbs like git push, git pull instead of flags.
I think this is a bit more logical and avoids polluting the “flag space”. I’m not quite happy with the command line parser yet, it needs some more attention.
One of the chips (winbond 32JVSIQ 2012 on a carrier board) responded with the following messages,
I’m not sure how to interpret and react to the error messages,
SPI> (1)
Probing:
Device ID Manuf ID Type ID Capacity ID
RESID (0xAB) 0x15
REMSID (0x90) 0x2b 0xde
RDID (0x9F) 0xef 0x40 0x16
SFDP (0x5A): found 0x50444653 "PDFS"
Version: 1.5
Headers: 1
**Param Table 0**
Type Ver. Length Address
Table 0 JEDEC (0x00) 1.5 64 0x010000
Error: record too long to fetch! Skipping...
If it is correct, it is a later version of SFDP that I knew exists I’ve only seen v1.0, this seems to be v1.5.
JEDEC notes:
SFDP Minor Revision Number
This 8-bit field indicates the minor revision number.
Minor revisions are changes that add parameters in existing Reserved locations, or
clarifications to existing fields. Minor revisions do NOT change overall structure of
SFDP.
NOTE Minor Revision starts at 0x00 and may only be revised by JEDEC.
So we should still be able to read it I think. I’m going to increase the buffer size.
I am also going to change the SPI pins names. It’s annoying.
I pushed an update. If you have a chance, in SPI mode could you please try:
flash -i
and
flash -p
Init and probe use different libraries to read the chip data.
I found the v1.5 and v1.6 spec. I check the flash library, and it seems to support them. My analysis tool (macro 1) does not support it (yet). I will get one of those chips because all my samples are v1.0.
I located a larger version of the chip (128) that has v1.5 JEDEC tables. flash -i inits the chip successfully. -p (same as macro (1)) does not, but I wrote that as a “getting to know you” code before installing the flash library that does support multiple table versions (1.0, 1.5, 1.6). For now, I’ll check the version when we probe and reject versions not yet supported.
However, I’m still not sure why flash -i isn’t working with your chip. Are the hold and WP pins pulled high some how?
I;m getting inconsistent results. I’ll try to give more detail as soon as I can figure out the pattern. In one case, I followed the SPI (1) with a “flash” command, and then the (1) macro failed. I’m changing HOLD/WP and the same actions gives different results. Right now I am getting
SPI> (1)
Probing:
Device ID Manuf ID Type ID Capacity ID
RESID (0xAB) 0x7f
REMSID (0x90) 0x7f 0x7f
RDID (0x9F) 0x7f 0x7f 0x7f
SFDP (0x5A): not found
SPI> flash
Flash device manufacturer ID 0x7F, type ID 0x7F, capacity ID 0x7F
Error: SFDP signature error. It must be 0x50444653 'SFDP'
Warning: Read SFDP parameter header information failed. The SPI_FLASH does not support JEDEC SFDP.
Error: Flash device not found
Error: device not detected
In your post you say that HOLD and WP should be high. So that is what I am doing. I’m still a learner, so excuse the confusion.
How do the various flash and macros assume the WP pin is used? Does it need to change WP - when testing to see if the chip can be erased? Or is it assumed to be HIGH?
It’s really odd that it gives some no-zero values, but the rest is garbage.
The important bit is that the WP and HOLD pins are held high. That could be a pull-up resistor or a bus pirate pin or even tie directly to power supply. flash command doesn’t do anything with them, they just need a high voltage to be disabled. I hook up two pins from the Bus Pirate and then enable the pullup resistors.
What voltage are you running at? What speed is SPi running at?
