Flashing a new or bricked VS1005G board

Discussion about writing software for VS1005 and the VSOS Operating System. Also posts about VS1005-related hardware design and device drivers should be posted here.
jedm@vpitech.com
Senior User
Posts: 43
Joined: Wed 2016-11-02 22:50

Re: Flashing a new or bricked VS1005G board

Post by jedm@vpitech.com » Mon 2016-12-12 16:48

That helps but from initspi I'm getting the following (from VSIDE I just get the last 5 lines). This is the result of recompiling 341 with #define USE_INTERNAL_FLASH in vsos_vs1005g.c

c:\Users\jedm\VSOS_341>c:\Users\Jedm\VSIDE\bin\vs3emu -chip vs1002b -m mem_desc.
extflash -monaddr 0x8000 -s 115200 -p 6 -l c:\Users\Jedm\VSIDE\bin\intflash1005g
.bin -c e.cmd
VSEMU 2.2 Nov 12 2010 16:48:42(c)1995-2010 VLSI Solution Oy
Using serial port 6, COM speed 115200
Waiting for a connection to the board...

Caused interrupt
Chip version "1005"
Stack pointer 0x3e0, bpTable 0x92e8
User program entry address 0xa747
c:\Users\Jedm\VSIDE\bin\intflash1005g.bin: includes optional header, 28 sections
, 977 symbols
Section 1: startup page:0 start:128 size:3 relocs:2 fixed
Section 2: bss_x page:1 start:2160 size:1665 relocs:0
Section 3: OpenRescueImage page:0 start:131 size:13 relocs:1
Section 4: ReadRescueImage page:0 start:144 size:41 relocs:3
Section 5: Build32YDowncount page:0 start:185 size:32 relocs:1
Section 6: ReadIFlashStatus page:0 start:217 size:22 relocs:2
Section 7: SetIFlashWriteEnable page:0 start:239 size:23 relocs:2
Section 8: WriteIFlashStatus page:0 start:262 size:20 relocs:2
Section 9: SpiWaitStatus2 page:0 start:282 size:65 relocs:9
Section 10: const_x page:1 start:3825 size:1911 relocs:0
Section 11: EraseIFlash page:0 start:347 size:116 relocs:23
Section 12: WriteIFlashPage page:0 start:463 size:107 relocs:24
Section 13: ReadIFlashPage page:0 start:570 size:41 relocs:7
Section 14: DumpFlash page:0 start:611 size:78 relocs:20
Section 15: TestSpeed page:0 start:689 size:422 relocs:75
Section 16: init_x page:1 start:5736 size:16 relocs:3
Section 17: WriteImage page:0 start:1111 size:422 relocs:87
Section 18: WriteImageMap page:0 start:1533 size:657 relocs:206
Section 19: main page:0 start:2190 size:231 relocs:58
Section 20: const_y page:2 start:1280 size:870 relocs:0
Section 21: const_x_str page:1 start:5752 size:37 relocs:0
Section 22: bss_y page:2 start:2150 size:4096 relocs:0
Section 23: FPutc page:0 start:2421 size:15 relocs:1
Section 24: fprintf page:0 start:2436 size:23 relocs:2
Section 25: printf page:0 start:2459 size:23 relocs:2
Section 26: VS_stdiolib page:0 start:2482 size:110 relocs:32
Section 27: strcmp page:0 start:2592 size:11 relocs:2
Section 28: VS_stdiolib$0 page:0 start:2603 size:24 relocs:5
Starting erase
Starting VS1005g internal SPI Flash prommer v2015-12-11...
Default SPI speed 20.0 Mbit/s
Serial Flash RDID: manufacturer 0 (C2), type 0 (20), density 0 (14)
Bad RDID, quitting
Failed. Press Close/Cancel on VSIDE.
^CTerminate batch job (Y/N)? y

User avatar
Panu
VLSI Staff
Posts: 2388
Joined: Tue 2010-06-22 13:43

Re: Flashing a new or bricked VS1005G board

Post by Panu » Mon 2016-12-12 19:59

Hi!

Can you check the voltage in the FVDD pin? And how it behaves when you start the prommer?

I'm thinking: for security reasons, boot from internal flash cannot be prevented if the internal flash has a runnable image. So when you start the internal flash prommer, the program that was previously written to the internal flash has already started to run, and that program might have configured the chip to a weird state which the prommer routine fails to handle. We might need to do some detective work to find out what is going on inside the IC.

Also, the hardware has a locking mechanism which physically prevents any access to the internal flash if it's proteced. Specifically, if the flash is not empty and does not start with an OK_TO_UNLOCK directive, the flash chip is locked out before giving UART or even factory test access to the IC. This might correspond with getting an all-zeros reply to RDID, but it's not the only possible reason.

The internal flash prommer tries to write a RESCUE_IMAGE to the beginning of the flash, which can help to erase and unlock a flash. That's option 2 in viewtopic.php?f=13&t=681#p6867. Would that be possible for you to try to trigger?

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

jedm@vpitech.com
Senior User
Posts: 43
Joined: Wed 2016-11-02 22:50

Re: Flashing a new or bricked VS1005G board

Post by jedm@vpitech.com » Mon 2016-12-12 20:29

I'm using a breakout board. So I assume you want the corresponding NFDIO pins pulled high?

FVDD as measured on breakout board 1uf CF1 is 3.2 or so volts.

jedm@vpitech.com
Senior User
Posts: 43
Joined: Wed 2016-11-02 22:50

Re: Flashing a new or bricked VS1005G board

Post by jedm@vpitech.com » Fri 2017-04-14 23:32

Back to working on the bricked BOB.

1) We can run debug on it bringing up 3.41 through the serial port - the SPI flash appears hosed though. We can see the USB support coming up and Windows says it has to reformat the 800+ K however, this fails. So: the CPU is working, I can fiddle 3.41 (I changed \nHello\n\ to \nHello Jed\n successfully).

2) We tried debrickers 2 3 and 4 but when we try to flash the working 3.41 image we get:

Code: Select all

Starting VS1005g internal SPI Flash prommer v2015-12-11...
  Default SPI speed 20.0 Mbit/s
  Serial Flash RDID: manufacturer  0 (C2), type  0 (20), density  0 (14)
Bad RDID, quitting
Failed. Press Close/Cancel on VSIDE.
3) We tried initspi.bat:

c:\Users\Jedm\VSIDE\bin\vs3emu -chip vs1005 -m mem_desc.extflash -bc any -monaddr 0x8000 -s 115200 -p 7 -l c:\Users\Jedm\VSIDE\bin\intflash1005g.bin -c e.cmd

in various combinations of vs1002b, vs1053, etc (strings found in vs3emu), different versions of mem_desc, etc. vs1002b seems to show a lot of messages but gets the empty RDID. vs1005 just hangs.

A while back you said you were working on v3emu. Any progress? Need some help?

User avatar
Panu
VLSI Staff
Posts: 2388
Joined: Tue 2010-06-22 13:43

Re: Flashing a new or bricked VS1005G board

Post by Panu » Sat 2017-04-15 11:10

It does seem like the internal flash is cut off, and there's basically two possible reasons: 1) it's locked down by security or 2) it doesn't have power. Hmm. Right, let's try to narrow this down a bit. I have been working on a new universal prommer program for the PC to make more sense of the dozens of programming options on our various ICs. I've been tied up with another urgent project for about 8 weeks, but I'll be able to resume work on the prommer soon. Do you want to try out a very early beta? I can get it for you when I go to work next week.

VS3EMU options: use memory description that allows access to all the memory. You should find it with a name such as "debug_use_all.mem" or something similar.

The different chiptypes mainly have quite minor differences; for example chiptype vs1005 disables VS1005 power button timer reset interrupt at startup, so that the prommer is not inadvetently cut of by a watchdog reset. Not sure why you experience so much differences. But it's good to know that when you switch on the VS1005, it will watchdog reset once after something like 8 seconds unless the software configures it properly and disables that reset. It may play a role in your experiences. Sometimes the initial power up fails, but the subsequent watchdog reset brings up the chip in 10 seconds. And similarly, it may trigger in the middle of programming operation, although the prommer program should prevent it.

Use an oscilloscope to check that the FVDD is constant: that the ROM software doesn't cut it off somewhere in the middle.

I think it would be really helpful if I could work with you when I develop the new prommer. You seem to have experienced just about all the failure mechanims that we know of, so it's a good test case... :D

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

jedm@vpitech.com
Senior User
Posts: 43
Joined: Wed 2016-11-02 22:50

Re: Flashing a new or bricked VS1005G board

Post by jedm@vpitech.com » Tue 2017-04-18 23:31

I'd be happy to help even after hours. Working the BOB, I did the following experiments.
Dead Break out board experiments.

--------------------------------------------------------------------------------
1) Did stand alone Hello World program. Works great!

--------------------------------------------------------------------------------
2) VSIDE 3.41. VSOS_341_Int project. Compiled, run through debug with following output:


Hello VPI!
VSOS 3.41 build Apr 18 2017 12:25:54
VLSI Solution Oy 2012-2016 - www.vlsi.fi

Starting the kernel..
Starting Devices...
Internal Flash

Installed system devices:
S: SPI Flash 0000.
E'Device not open'

0 driver(s) loaded.

VSOS running with 5 tasks:
Task I/O Stack:0010-020f (512w), free:337
Task Int Stack:0210-024f ( 64w), free:28
Task Net Stack:0250-0251 ( 2w), free:1
Task UI Stack:0252-0253 ( 2w), free:1
Task DECOD Stack:0254-03cf (380w), free:379

Interrupts: INT0_DAC:2->37765 INT13_RX:1->32923 INT15_TI1:1->525 INT16_TI2:1->10499

Load S:INIT.AP3...E'Device not open'

S:INIT.AP3 not found.
Nothing to do.USB publishing disk: SPI Flash 0000.
Size 0.9 MB.
SCSI START
BRST
BRST


Windows says it's not formatted and attempts to do so fail with a worthless Microsoft error message.

--------------------------------------------------------------------------------
3) VSIDE 3.41 again - this time trying to write to flash.
Prommer utility window...

VS1005G Internal Flash Prommer
Image file: eeprom.img (35766 bytes, last modified 30 minutes ago)
Target platform: VS1005
Communicate via UART: COM5, intial speed 115200
Prommer: intflash1005g.bin (mem_desc.extflash)
Programming the memory! See the stdin/stdout console for details

Stdin/Stdout console shows:
Starting VS1005g internal SPI Flash prommer v2015-12-11...
Default SPI speed 20.0 Mbit/s
Serial Flash RDID: manufacturer 0 (C2), type 0 (20), density 0 (14)
Bad RDID, quitting
Failed. Press Close/Cancel on VSIDE.

--------------------------------------------------------------------------------

4) VSIDE 3.40 - fixed compile problem in devHwSpi.c

typedef struct devHwSpiHardwareInfoStruct {
/* NOTE! This structure will leak into deviceInfo[] because there are only
6 words of space in hardwareInfo[]. Nevertheless, this is not a
problem since this device never has a file system, so we can use
the extra words. */
volatile __y spiRegisters *regs;
u_int16 csPin;
u_int16 ioChannel;
u_int16 clockDivider; // WILL BE REPLACED WITH maxClkKHz in 2016 - see latest kernel sources
...

devHwSpi.c referenced maxClkKhz so I switched it back to clockDivider (probably a loser).
Same result as above. SCSI USB comes up but the system can't format.

--------------------------------------------------------------------------------
5) VSIDE 3.40 same image, now writing to flash. Same errors as step 3.

User avatar
pasi
VLSI Staff
Posts: 1377
Joined: Thu 2010-07-15 16:04

Re: Flashing a new or bricked VS1005G board

Post by pasi » Fri 2017-04-21 17:04

Stupid question time: It looks like the internal SPI FLASH is not detected. It could be due to access to it being disabled during boot. (Does your VS1005 has internal SPI FLASH? What is the code at the top of the IC?)

If the vs1005 is supposed to have internal FLASH, try connecting IOVDD2 (FVDD) and IOVDD together.
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

jedm@vpitech.com
Senior User
Posts: 43
Joined: Wed 2016-11-02 22:50

Re: Flashing a new or bricked VS1005G board

Post by jedm@vpitech.com » Fri 2017-04-21 17:25

Yes it does - it's one of your breakout boards and the chip says VS1205g on it. I'm tempted to abandon this board since we now have multiple working versions of our own.

We have successfully put VSOS 3.41 on some of our new boards though we're unsure of why it works. In all cases FVDD and IOVDD are hardwired together. Two of the boards may have odd serial port problems.

The lesson learned so far is not to hard wire the battery until everything is programmed. There's too many catch 22's until all the software's loaded onto the SPI flash.

Two somewhat related questions:

1) Is there a software way of forcing the SCSI internal SPI flash service? I'd like to create a backdoor for loading software after we button the boards up (they're going underwater).
2) The SetPower function appears to be internal (32763 address). SetPowerOff(PCL_SDCARD) seems to set GPIO0 bit 7 to 0 which appears to be unrelated to the SD card. Is there a reason for this? We're using that bit to turn on/off the SD card special regulator and I have to refiddle that bit in devSdSdExt.c the SDSDX.dl3 application. I like using your stuff without modifying it.

Thank you for your response. Things are now progressing well here.

Jed

User avatar
Panu
VLSI Staff
Posts: 2388
Joined: Tue 2010-06-22 13:43

Re: Flashing a new or bricked VS1005G board

Post by Panu » Tue 2017-04-25 14:05

Hi!

Great that things are proceeding! The breakout boards have had some issues - seems our CM didn't have the soldering profile quite spot on, so there have been some bad contacts in them, that's at least one possible malfunction mechanism...

Anyway, here's a very early alpha of the prommer, this one containst the win32 executable, and the promming module for VS1005g, and a bin file that contains the rescue image for VS1005g internal flash. You can see if you can establish any kind of communication with the board using this, highly experimental alpha version of the prommer.
vsprom9.png
vsprom9.png (42.04 KiB) Viewed 371 times
Ideally you should see something like the above, with the VS1005g chip detected, and then you can select the internal flash and write the rescue image to it. You can also read and copy flash contents, but beware - most of the UART cables are not very stable, it may take several tries to read or write a large image.

-Panu
Attachments
vsprom9test.zip
(218.89 KiB) Downloaded 23 times
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

jedm@vpitech.com
Senior User
Posts: 43
Joined: Wed 2016-11-02 22:50

Re: Flashing a new or bricked VS1005G board

Post by jedm@vpitech.com » Tue 2017-04-25 17:02

Ran the program, it does seem to talk to the BOB that we're having trouble with. Serial port communication is through an FTDI chip on a board with reset/power-on switch and the BOB also connected to USB. It doesn't seem to like this board. After clicking connect, I clicked Use 64k, did the Load from file with your rescue image and clicked Write.
vsprom9.png
vsprom9.png (82.51 KiB) Viewed 368 times
On a different BOB (one that's working so I'm loathe to change it), I just did a read and got:
Attachments
working.png
working.png (79.76 KiB) Viewed 368 times

Post Reply

Who is online

Users browsing this forum: No registered users