PROBLEM SOLVED - Can I program a W25Q80DV in circuit?

[Phil1977]

Hi,

I have a device (a FNIRSI SG04 process calibrator) that does not start anymore after a failed firmware upgrade.

Obviously the code is stored in a W25Q80DC chip from winbond in an accessible SOIC8 form factor. I have different firmware revisions as a .bin file.

Does anyone know if it´s possible to flash this device with a SOIC8-test-clip in circuit? Can anyone recommend a tool or Raspi-code or anything else to flash via SPI?

I´d desolder the chip only as a measure of last resort. The SG04 has quite a lot of analogue blocks and I don't want to thermally stress them if it´s not the only alternative to discarding.

Thanks in advance!

[amyk]

You can try to apply a current-limited voltage to see if it attempts to power up the rest of the system; if it does, you will need to lift the Vcc pin on the IC before using a chip clip.

[HwAoRrDk]

If you can find a way to hold the SPI master (i.e. MCU) in reset state, then you should be able to do it in-circuit. This way the master will not make any attempts to communicate and will also have all its connected pins hi-Z. Maybe if you can find a programming header for the MCU that features reset, you can jump it to ground.

Assuming the flash is operating at 3.3V, you can do the flash programming using a Raspberry Pi with its native SPI interface and the flashrom utility. You need to specify which SPI interface to use with -p linux_spi:dev=/dev/spidevX.Y. See man page for details.

I would advise putting some series resistors on the SPI connections just in case. Nothing too large, 1k is good. And you can turn down the SPI clock speed by adding the optional spispeed parameter to the above arg, to avoid problems due to janky temporary wiring. (IIRC the default is something like 10 MHz.)

[HwAoRrDk]

I looked into this a bit more. It would seem FNIRSI have made it easy to control the reset line of the MCU.

In looking for teardown pictures, I found a YouTube review and teardown by Kerry Wong of the SG-003A, which seems to be fairly similar to the SG-004A. In that, you can see the NRST pin of the MCU (Geehy APM32F103VCT6 in LQFP100) - right next to the two crystal oscillator pins - is connected to an unpopulated button footprint on the top edge of the circuit board.



Looking at another YouTube review and teardown by DiodeGoneWild of the SG-004A, it appears that while they are using a different MCU (Artery AT32F403A), it shares the same (or very similar) LQFP100 pin-out, so the NRST pin is in the same place. As there is a similar unpopulated button footprint on the board edge, it follows that even though the exact route of the trace coming from the NRST pin is obscured by passing to another layer through a via, it's highly likely it connects to this button just like on the SG-003A.



So, to hold the MCU in reset during flash SPI programming, you can likely simply short the two pads of this button footprint.

Here's also some more details from notes I made when I did a similar thing - programming an SPI flash chip in-circuit from a Raspberry Pi - a while ago:


If not already present, install flashrom utility: sudo apt install flashrom

Enable SPI0 bus on Raspberry Pi:

1. Edit /boot/config.txt.
2. Uncomment (or add) line with "dtparam=spi=on".
3. Reboot Pi.
4. Confirm that /dev/spidev0.0 and /dev/spidev0.1 exist.

Connect SPI flash chip to Raspberry Pi GPIO header as follows:

Flash Pin	Pi GPIO Pin
1 (CS)	24 (GPIO8, SPI0 CE0)
2 (SO)	21 (GPIO9, SPI0 MISO)
3 (WP)	[Jumper to VCC]
4 (GND)	20 (GND)
5 (SI)	19 (GPIO10, SPI0 MOSI)
6 (SCK)	23 (GPIO11, SPI0 SCLK)
7 (HOLD)	[Jumper to VCC]
8 (VCC)	17 (3V3)

Writing ROM image to chip:

1. Check chip responds to communication: sudo flashrom -p linux_spi:dev=/dev/spidev0.0
2. Write data: sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -w <filename.bin>
3. Verify data (optional): sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -v <filename.bin>

Note that flashrom requires data file size to match size of flash. If ROM image is not big enough, pad with 0xFF bytes to required size:

srec_cat <filename.bin> -binary -fill 0xFF 0 <size> -o <filename-padded.bin> -binary

Change device argument to "linux_spi:dev=/dev/spidev0.0,spispeed=NNN" to set SCK speed (value N in kHz).


I mis-remembered before about default SCK speed - it's 2 MHz, but that's still rather fast, so you'll probably want to slow it down to a few hundred kHz.

[abyrvalg]

These APM32/AT32 MCUs run firmware from internal flash, so perhaps W25Q is a wrong target.

[Phil1977]

Thousand thanks for the detailed descriptions!

Currently I´m trying to find out if I can still get a warranty repair/exchange of the failed unit - but I do not have realistic hopes, I didn't get the device from the manufacturers store but somewhere else.

Prior to the failed update the device appeared as a flash-drive in Windows so you can easily program the firmware. I also would suspect that the bootloader for the flash-drive is in the MCU but not in the external flash. Anyhow, I´d give it a try to read the W25Q, compare it roughly to the .bin files and if there are any similarities I´d try to reprogram it. Even if it doesn't work you learn a lot about repairing modern stuff in general.

I´ll keep you updated.

[HwAoRrDk]

These APM32/AT32 MCUs run firmware from internal flash, so perhaps W25Q is a wrong target.

Ah, yes, that's right. That fact passed me by - should have looked more closely at the MCU datasheet.

I also would suspect that the bootloader for the flash-drive is in the MCU but not in the external flash. Anyhow, I´d give it a try to read the W25Q, compare it roughly to the .bin files and if there are any similarities I´d try to reprogram it.

I was going to say that the size of the .bin firmware image file you already have will be a hint as to where its home is, but given that the W25Q80DV has a capacity of 1 MB, and (assuming your unit is identical) the AT32F403AVGT7 also has an on-chip flash capacity of 1 MB ('G' in part number = 1 MB flash), that is not a good lead.

The AT32F403A datasheet does say it features "SPIM interface: Extra interfacing up to 16 Mbytes of the external SPI Flash (as instruction/data memory)", so it appears the MCU is actually capable of running code from SPI flash, so the bootloader on internal flash hypothesis is feasible. But having 1 MB of MCU flash would be rather overkill for just a bootloader...

Given that the SG-004A has a "History Record" feature, I am thinking the SPI flash might only be used for this data.

[ebastler]

I was going to say that the size of the .bin firmware image file you already have will be a hint as to where its home is, but given that the W25Q80DV has a capacity of 1 MB, and (assuming your unit is identical) the AT32F403AVGT7 also has an on-chip flash capacity of 1 MB ('G' in part number = 1 MB flash), that is not a good lead.

I haven't looked at the datasheet of this particular MCU. Does it have BOOT0/BOOT1 pins which define where it boots from? Can the connections to those be traced, or the voltage levels upon boot be measured?

[pcprogrammer]

To solely target the W25Q80DV, I would suggest to look closely to the parts near the chip. It might be that they added a diode in series with the VCC pin of the W25Q80DV. I have seen this in the FNIRSI 1013D and 1014D for both the FLASH chips used in these devices.

If that is the case it is possible to use a clip and power only the W25Q80DV itself. But be careful and make sure the programmer being used is 3.3V on not only the VCC pin, but also on the SPI pins. I say this from experience having blown the FLASH in one of my 1013D's. The programmer used 5V on the SPI lines. 

[HwAoRrDk]

I haven't looked at the datasheet of this particular MCU. Does it have BOOT0/BOOT1 pins which define where it boots from? Can the connections to those be traced, or the voltage levels upon boot be measured?

The datasheet says it has both BOOT0 (pin 94) and BOOT1 (pin 37). You can see in the screenshots I posted earlier that the resistor at a 45-deg angle above the chip is connected to BOOT0, for a pull-up or pull-down, but does not appear to go anywhere else. BOOT1 seems to have a trace disappearing away to the LCD screen. (Edit: actually, BOOT1 has no other function apart from GPIO PB2, so not 'XMC' LCD interface.) So, whatever those pins define as the boot mode appears to be fixed.

From the MCU reference manual:

BOOT1 and BOOT0 are used to set the specific memory from which CODE starts.
{BOOT1, BOOT0}=00/10, CODE starts from the main Flash memory
{BOOT1, BOOT0}=01, CODE starts from Boot code
{BOOT1, BOOT0}=11, CODE starts from SRAM

And from the datasheet:

Boot from the internal Flash memory. For the AT32F403AxG, user has an option to boot from any of two memory banks. By default, boot from Flash memory Bank 1 is selected. User can also choose to boot from Flash memory Bank 2 using the User System Data.

[...]

The bootloader is stored in boot code area. It is used to reprogram the Flash memory through USART1, USART2, or USBFS1. Of them, the USBFS1 supports crystal-less mode. If SPIM_IO0/1 pin is configured to be shared with USBFS1 pin, the SPIM Flash memory Bank 3 cannot be programmed through USBFS1.

I'm not sure exactly what it means when it talks about memory banks. But the internal flash memory is segmented into two areas: one 256 KB 'ZW' (zero wait state) memory, and one 768 KB 'NZW' (non-zero wait state) memory. I have a feeling it is talking about that, with "bank 3" being external SPI flash memory.

[abyrvalg]

OP, would you mind posting your .bin file? It should be quite easy to find out from which memory it should run by looking at vector table.

[Phil1977]

You can get the latest firmware (the one that destroyed my device) here:

https://www.fnirsi.com/cdn/shop/files/SG-004A_V2.11.zip?v=18145067921082521464

I can also send you a link to the previous version per PM.

[abyrvalg]

This .bin is built for 0x08005800 start address which fits MCU's internal flash. But you can't just erase the MCU and write this bin, it is not a complete image, there should be some bootloader at 0x08000000-0x08005800. Try reading out the flash if it is not protected. In any case, W25Q is wrong target.

[Phil1977]

If the bootloader is not in the provided file then it seems there must be broken more than just the program area. Of course I don't know FNIRSIs programming secrets, but isn't usually the USB-drive code in the bootloader - to just prevent the device from getting bricked if something goes wrong in the program area?

[abyrvalg]

We can’t be sure here, in the worst case the bootloader cold be damaged, or it just can’t detect some kind of damaged firmware and jumps straight to it, who knows. Try reading out the full flash to see what can be salvaged.
In the worst case (damaged boot or read protection set) here is a trick to fake the bootloader: cut first 0x5800 bytes of the main firmware and paste (insert, not overwrite) it at the beginning - this will duplicate fw’s vector table in the bootloader area and the CPU will jump straight into the fw upon reset. You’ll loose the bootloader functionality (whatever it was), but the main fw could work in some cases (if it doesn’t use code/data from boot).

[HwAoRrDk]

Can't imagine why they would have their own bootloader when the MCU has its own USB bootloader.

There is a UART header (three pins, RX, TX, GND) next to the MCU. Could try connecting to that (with a USB-UART adapter - note it'll probably need to run at 3.3V, not 5V) and see if any code that is managing to run is spitting out any messages that might be informative. I would imagine a custom bootloader might do so. They obviously didn't put that header there for no reason.

[abyrvalg]

Can't imagine why they would have their own bootloader when the MCU has its own USB bootloader.

Their custom bootloader emulates a mass storage device, simplifying the update process significantly.

[Phil1977]

Good news everyone (TM): The SG-004A is running again without any solder activities.

After a long and unsuccessful discussion with the seller, I started to further disassemble the unit. Unexplainably but true, the bootloader showed me the flash drive again after disconnecting the display. Maybe the code skips some initialization routines if the display is not connected, but obviously it enabled the firmware flashing procedure.

After copying the old FW 2.9 back to the device it was alive again. Also the update to FW 2.11 was flawless this time.

Now I just have to check the calibration before it get´s back into the toolbox.

Thanks anyhow for all the help! Some inner child of mine nearly hoped for some worse problem, this nearly was too easy.

[Mike1233]

Did you find any problems with the version 2.11?
Is it better that if i update my SG-004A first with 2.9 and then version 2.11?
Thanks.

[Phil1977]

Yes, as written in the other thread dedicated to the SG-04 I´ve heard from one other guy who bricked his device by skipping V2.9 and flashing directly to V2.11.

If V2.11 is running then it seems to be running fine. But I don't have a changelog and only noticed a corrected typo so far.

[Mike1233]

Thank you for the reply. I first did the update with 2.9 and then i did use 2.11.
My device is still alive so i think everything is fine.

This is what i just saw in the folder of the 2.11 firmware.



SG-004A    V2.9  2023/05/11

1.修复 设置  输出24V中工程量上限显示0问题

SG-004A   V2.10  2023/05/18
1.修改热电偶输入显示问题

SG-004A   V2.11  2023/06/12
1.更新热电偶输出问题

----------------------------
SG-004A    V2.9  2023/05/11

1. Fix the problem that the upper limit of engineering quantity in "Settings" output 24V shows 0

SG-004A   V2.10  2023/05/18
1. Modify the thermocouple input display problem

SG-004A   V2.11  2023/06/12
1. Update thermocouple output problem