IceCore myStorm firmware

Folknology 2019-08-02 08:54:39 UTC #221

I wish I new that, it isn't obvious..

@lawrie can you do a quick diff on mystorm.cpp with working your version against current branch see if there is anything obvious..

We have mostly been messing about calling enable/disable flash in different places, I cannot recall other relevant changes

Folknology 2019-08-02 09:29:26 UTC #222

What I am thinking is that if there isn't a valid image in the flash The Ice40 does something odd which places the flash (and maybe the Ice40) into a intermittent state, purgatory for flash!

lawrie 2019-08-02 09:36:18 UTC #223

Don't understand. The repository hasn't changed for 3 days, and my version is the same as it, as I have merged all the changes.

AndyCap 2019-08-02 09:36:19 UTC #224

OK, stepping though the code in the debugger gives 0xff,0xff,0xff.

Running the code causes the hang.

lawrie 2019-08-02 09:38:12 UTC #225

Yes, I had a problem when I had an invalid image in flash. I fixed it by overwriting the first 4 bytes with zeroes.

Folknology 2019-08-02 09:42:27 UTC #226

do you still get a 0xFF .. at startup?

lawrie 2019-08-02 09:44:42 UTC #227

Looking back at this thread, what happened to me when I had an invalid flash image was that the usb to uart stopped working, but that was probably due to a hang that I didn't look for - https://forum.mystorm.uk/t/icecore-mystorm-firmware/629/116

AndyCap 2019-08-02 09:45:20 UTC #228

So would an erased flash be seen as an invalid flash image?

Folknology 2019-08-02 09:48:10 UTC #229

I am wondering where it gets stuck in the Hal read call, I am wondering if this could be caused by interrupt priorities issues with HAL Ticks, even when stuck I can still program the Ice40..

AndyCap 2019-08-02 09:51:06 UTC #230

Tried here with an erased flash and a zeroed flash, same issue.

Interestingly sometime I get the 0xff,0xff,0xff once after reboot and then a hang, but usually just a hang at boot up.

lawrie 2019-08-02 09:51:16 UTC #231

Just tried and I got something new:

cat /dev/ttyACM0 
0xFF,0xFF,0xFF
0x05-ERRS
0x1F,0x84,0x01

A second and third press of the button, fixed it. I haven't seen that before.

I currently have a valid image in flash.

Things are currently working for me, but I am doing the flash writing from my SoC not the firmware.

AndyCap 2019-08-02 09:52:52 UTC #232

Lawrie could you erase the whole flash and then reboot and try it?

lawrie 2019-08-02 09:55:10 UTC #233

What command are you using to erase the whole flash? I don't have an easy way to do that at the moment.

AndyCap 2019-08-02 09:58:08 UTC #234

void CADFlashHandler::EraseFlash(void)
{
	PollForReady();

	WriteEnable();

	uint8_t uCommand = 0x60;

	gpio_low (ICE40_SPI_CS);
	write(&uCommand, 1);
	gpio_high(ICE40_SPI_CS);

	Disable();

	PollForReady();

}

AndyCap 2019-08-02 09:59:22 UTC #235

HAL_Tick() seems to have gone.

It is always returning the same value here, could be the cause

HAL_IncTick(void) is not being called, has a timer gone wonky?

Edit: ah not quite true SysTick_Handler() (which calls it) is being called and then stops being called.

lawrie 2019-08-02 10:09:47 UTC #236

I have never used the bulk erase command, which seems to be either 0x60 or 0xc7. I always erase 32kb with the 0x52 command.I believe any of the erase commands set all bits to 1. I don't know if the ice40 will treat that as an invalid image.

lawrie 2019-08-02 10:18:54 UTC #237

I think I recovered from my problem writing to flash by removing the call to reset in setup so it stopped trying to load from flash at start-up, then wrote zeroes to the first 4 bytes, or wrote an valid image to the flash, and then put the reset back.

AndyCap 2019-08-02 10:22:25 UTC #238

OK I think I have found the issue here.

If the Flash stuff is called from inside loop() I get the 0xff, 0xff, 0xff.

If it is called from within the usb handler then you get the hang, the systick interrupt is disabled so the timeout doesn't work either.

I'm guessing it may not be best to use the hardware spi from within the usb callback

Folknology 2019-08-02 10:36:05 UTC #239

This will likely require interrupt priority changes in order to function

AndyCap 2019-08-02 10:37:42 UTC #240

So are you getting your hang when called from the usb handler or from loop()