Add send raw commands and/or cheatsheet menu

[alejandro-alzate]

Description

So I was trying to flash a 16MB winbond rom but i couldn't get it to do it.

Now external sources said that the approach is to send a WREN command to let the chip set the WEL flag which the opcode of the command is 0x06 so it would be cool on those edge cases where the user changes the WEL flag on the properties panel it silently sends that command or having a list of known commands to execute.

flashrom got it although never told me. Since flashrom poked the rom chip IMSprog now can write to it (although said WELflag is still cleared).

I don't really exactly what did flashrom that forced that chip to cooperate but threre's that.

Also Just something off topic before I go: if I get time to do it I'll do the Spanish translation for you guys so my homies can use it :)

Usage tips

• Please use the 👍 reaction to show that you are interested into this.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this.
• Subscribe to receive notifications on status change and new comments, you can do also without add comment.

[bigbigmdm]

Hello, @alejandro-alzate !
Any programmer sends a WREN command before starting to write. IMSProg sets WREN DIASBLE at the end of the write. For complicated cases with chip locking there is a panel for working with status registers - [ctrl]+P. In this menu, set all bits of the first status register to zeros and write data to the register. Then repeat the chip write operation.

[alejandro-alzate]

Wait it does?
That's weird that chip wouldn't budge, it was read only (I followed your BP3 & BP4 advice on the readme to read it), but when i just listed it with flashrom, IMSProg would now write it. That's weird, I might have let slipped a bug?

[bigbigmdm]

This is very strange. Do you connect the chip to the programmer directly or with alligator clip?

[alejandro-alzate]

Direct. I took the chip off of the board.

Just this morning tested the alligator with other chip on another board and that did caused issues. The 3.3v was enough to power the processor so it conflicted the SPI bus..

So from now on bare metal connection it is...

[bigbigmdm]

This is correct. Can you post a screenshot of the registers from IMSProg?

[alejandro-alzate]

Uh that's gonna be a though one i soldered the thing on the board,
But I remember that i had to clear only BP3 (BP4 was already clear), and WEL was never active before flashrom poked at it.

I think i saw it on 1 after the flashrom incident...

[alejandro-alzate]

But here is my bash history with the flashrom nonsense

 2000  pip install spidev
 2001  sudo apt-get install bossa-cli
 2002  ls /dev/spidev*
 2003  modprobe spidev
 2004  sudo modprobe spidev
 2005  ls /dev/spidev*
 2006  uname -r
 2007  lsmod | grep spidev
 2008  sudo modprobe spi_bcm2835
 2009  sudo modprobe spidev
 2010  sudo apt-get install build-essential libncurses5-dev bison flex libssl-dev
 2011  dmesg | grep spi
 2012  zcat /proc/config.gz | grep SPI
 2013  CONFIG_SPI_MASTER=y
 2014  CONFIG_SPI_SPIDEV=y
 2015  ls /dev/spidev*
 2016  sudo flashrom -p list
 2017  sudo flashrom --programmer=ch431a_spilist
 2018  sudo flashrom --programmer=ch431a_spi list
 2019  sudo flashrom --programmer=ch341a_spi list
 2020  sudo flashrom --programmer=ch341a_spi --help list
 2021  flashrom 
 2022  sudo flashrom --programmer=ch341a_spi
 2023  sudo flashrom -L
 2024  sudo flashrom -p ch341a_spi
 2025  dmesg | grep ch34
 2026  cd Desktop/ROMS/HIKVISION/DS-7208HQHI-K1/
 2027  ls
 2028  sudo flashrom -p ch341a_spi -w ~/Downloads/digicap.dav 
 2029  binwalk ~/Downloads/digicap.dav 
 2030  sudo apt install binwalk 
 2031  binwalk ~/Downloads/digicap.dav 
 2032  binwalk backup.bin
 2033  binwalk -e ~/Downloads/digicap.dav
 2034  ls
 2035  sudo apt-get install squashfs-tools
 2036  mksquashfs _digicap.dav.extracted/ repacked.sqsh
 2037  ls
 2038  ll
 2039  dd if=/dev/zero bs=1M count=1 >> repacked.sqsh
 2040  zcat backup.bin > decompressed_file
 2041  sudo flashrom -p ch341a_spi -w repacked.sqsh
 2042  sudo flashrom -p ch341a_spi -w _digicap.dav.extracted/6C.cramfs
 2043  history 
 2044  cp _digicap.dav.extracted/6C.cramfs ../cramfs.bin
 2045  dd if=/dev/zero bs=1M count=1 >> ../cramfs.bin 
 2046  mv ../cramfs.bin .
 2047  ls
 2048  ll
 2049  ghex cramfs.bin
 2050  ghex cramfs.bin&
 2051  watch -n .3 ll
 2052  which ll
 2053  $(which ll)
 2054  nano ~/.bashrc 
 2055  watch -n .3 ls -alF
 2056  sudo flashrom -p ch341a_spi -w cramfs.bin 
 2057  history 

[bigbigmdm]

Once again, WEL is not an indicator. It's something else.

[bigbigmdm]

Can you post the chip markings here?

[alejandro-alzate]

Winbond
25Q128JVSQ
From what I can make out (even rubbing chalk helped little).
IMS prog says that is a WINBOND 25Q128BV which...
Seems off...

Is this fella here (UF1)

[bigbigmdm]

@alejandro-alzate , thanks! I tested IMSProg with Winbond 25Q16, 25Q32, 25Q64 and 25Q256 chips.

[alejandro-alzate]

So i just have bad luck and got exactly the chip that is not on your test subjects huh?
I'm going to the hassle of heating the air gun thingy again, I'll give you those registers.

Here are the flags:

And a failed macro shot of the chip itself:

[bigbigmdm]

Please no need to torture the chip and PCB. I will look up the difference between the chips on datasheets.

[alejandro-alzate]

Please no need to torture the chip and PCB. I will look up the difference between the chips on datasheets.

Too late mate :/

At least this is like the third time and I have it still with all pads...
I updated my comment above with what you asked for.

@bigbigmdm How did it went your quest invoking the ancient runes of the datasheets?
Does the discrepancy in the part number matters?

[bigbigmdm]

Hi, @alejandro-alzate !
Datasheet: I can't find any difference between these chips.
Are you using the latest version of IMSProg (v1.4.3)?
I don't understand - The write-protect bits BP3 and BP0 are set to one. This includes the write-protect area of the chip. Are these bits not getting set to zero?

[alejandro-alzate]

Indeed 1.4.3 In fact I compiled it not knowing there was a ppa out there.

Before any write attempt

First Write attempt with IMS

Doing auto mode, for the first time froze the program which is weird. but the active light is on on the programmer.
And refuses to do anything.

Oop! wait i tried to do the flashrom thing and failed miserably

flashrom v1.2 on Linux 5.15.0-119-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi.
Reading old flash chip contents... 
cb_in: error: LIBUSB_TRANSFER_TIMED_OUT

cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
ch341a_spi_spi_send_command: Failed to read 4100 bytes
FAILED.
alejandro@lenovo:~$ 

But went smooth after doing the almighty "run the command again" trick.

flashrom v1.2 on Linux 5.15.0-119-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... 
Warning: Chip content is identical to the requested image.
Erase/write done.

After flashrom touches it this are the flags seems like BP3 and BP0 got cleared by flashrom.

Now both manual write and auto works like nothing happened
Here's auto:

Here's manual:
Just writing because seeing the bar fill feels like seeing paint dry to be honest.

I hope eeprom tech don't suffer the same flaw that ssd tech (limited writes, memory cell corroding)
Because all of those test I'm sure they're beating the heck outta the poor chip.
But at least doesn't heat like ssd drives do.

[bigbigmdm]

I have a feeling that writing to the status register 0 is not happening. Can you write ones into it, then reading, then write zeros and read?

[alejandro-alzate]

Something funny is going on:
What is on zeros won't change at all.
What is on ones refuses to change to zeros.
Did I cooked the chip?

Screencap zipped bc github can't cope with MKV and vlc won't transcode the video to mp4 correctly
2024-09-02 11-45-06.mkv.zip

[bigbigmdm]

Then don't. I think this problem will arise again. And then I'll fix it.

[alejandro-alzate]

Then don't. I think this problem will arise again. And then I'll fix it.

I mean I gave up trying to fix this board some time ago (Clearing DVR password by reflashing the firmware), but i'll help if you need some other tests...