IceCore myStorm firmware

[lawrie]

Why is it working for you but not me?

The original code was executing the loop one two few times, which corrupted the output image. I confirmed this by producing a test image with (32-bit) word i, containing i*4, as this made it easy to see if the right data was written to the right place in flash. It confirmed that the data was being corrupted by missing one byte in every 64.

My first go at fixing it counted n bytes incorrectly, which failed to write the last 2k of the image.

The code you posted has nbytes++ n the wrong place, so will only increase it every page, not every byte (until the last incomplete page).

I am convinced the code I just posted is correct, and works. I confirmed it with my test image, and then used it with real bitstreams.

[lawrie]

This is the code in my fork -

lawrie/IceCore/blob/USB-CDC-issue-3/firmware/myStorm/mystorm.cpp#L770

output/mystorm.raw in that repository works for me.

[lawrie]

Yes I return the led to the mode at the end of programming

My problem is that I was running some tests with short bitstreams, and it was not setting it back for them, and confusing me.

[Folknology]

Ok I just downloaded your version. The first time I ran it it failed. I then re powered the board and ran it again and it worked. Now it works everytime.

I need to check for any other differences, also it is clear that once you have a good flash image installed it behaves..

[lawrie]

Why is it working for you but not me?

If I start with an invalid image in flash, I have to do the non-flash configuration first, before pressing the mode button and doing a flash configuration. When I start with a valid image in flash, I don't have to do that.

[lawrie]

I need to check for any other differences, also it is clear that once you have a good flash image installed it behaves..

Yes. The only other difference I have in my version of mystorm.cpp is the removal of mode_led_toggle in erase_write, which is irrelevant.

[Folknology]

OK So I need to get all these changes merged into master this week for myStorm v0.6. In terms of modes we actually have up 4 different modes, we have 2 leds green and yellow to indicate which mode we are in, I was looking to wrap that part up along with errors etc.. over next few days, any thoughts?

[lawrie]

I was looking to wrap that part up along with errors etc.. over next few days, any thoughts?

Not sure what you are asking me. I don't really like modes at all, particularly ones that involve pressing buttons.

For flash writing, there are still various use cases to consider:

1. Writing bit stream to address 0 - DONE
2. Writing a warm boot configuration to address 0
3. Writing a bitstream to first warm boot image (probably address 0xa0)
4. Writing a bitstream to second warm boot image (probably address 0x28000)
5. Writing software binary to flash memory (probably address 0x50000)

A warm boot configuration includes a 160-byte header and two bitstreams. The second one isn't really necessary as it is a default. I am currently assuming we use the same mapping for a two-image warm boot configuration as the TinyFPGA BX. There is not much choice if you create it with icemulti, given the size of the flash memory. You could put the logic that icemulti uses to create the header into the firmware.

A software binary, which could be executed with XIP, or copied into RAM, can be any length, and could be written to other addresses.

To support warm boot configurations, a way to boot into the second (user) image without writing to flash, is needed.

The TinyFPGA BX tinyprog utility has options: -b to boot into user configuration (address 0x28000), -p to write to the user configuration, -u to write a software binary. It can combine these and write a bitstream and software binary in one go (useful for SoCs). You can also, optionally specify an address. It gets the length from the file parameter(s) you give it.

If you want to stick with modes, you could have a direct configuration mode, a flash configuration mode and a command mode for all these options.

[Folknology]

For flash writing, there are still various use cases to consider:

Writing bit stream to address 0 - DONE
Writing a warm boot configuration to address 0
Writing a bitstream to first warm boot image (probably address 0xa0)
Writing a bitstream to second warm boot image (probably address 0x28000)
Writing software binary to flash memory (probably address 0x50000)

Yup in all other cases (not Done so far) we need headers or wrappers etc.. for length and purpose as a minimum

[Folknology]

Not sure what you are asking me. I don't really like modes at all, particularly ones that involve pressing buttons.

Well the effect of this depends on which mode is default I guess. Is it such a hardship to press a button in order to access say advanced features that newbies might not want to start with?

Or do we look at it the other way have advanced first and other legacy modes from button presses?

[lawrie]

Well the effect of this depends on which mode is default I guess. Is it such a hardship to press a button in order to access say advanced features that newbies might not want to start with?

Or do we look at it the other way have advanced first and other legacy modes from button presses?

I am not too bothered which way you choose to do this. I can see the arguments either way. Two modes are probably sufficient, the direct configuration mode (compatible with Blackice) and a command mode with addresses and lengths.

I have said before that you could try to deduce the mode from the data received so the button press is not necessary, but using the programming USB port for the uart as well complicates this a bit.

[AndyCap]

Like Laurie I can't stand pressing buttons, doing this sort of stuff in the stream of data seems a better idea to me.

The stuff I have done uses the 4th byte of the header to determine what to do, so look for start of header: 0x7e, 0xaa, 0x99

Then read next byte 0xCS

Where C = Command nibble to direct to a system, So I have Flash, FPGA, Util etc
And S = Subcommand for that system.

So 0x7e = 7=fpga, e=write bitstream. Use existing code path

For flash I currently have a command byte nibble of 1 and currently 5 subcommands

0x10 - erase flash
0x11 - flash bitstream
0x12 - QueryFlash (debug)
0x13 - ProgramData
0x14 - ReadData

So to program ICE40 I do:

cat chip.bin > dev/blah

And to flash bitstream I do:

cat flashBitstream.bin chip.bin > dev/blah

flashBitstream.bin contains:

ff 00 00 ff 7e aa 99 11

[Folknology]

What is the difference between 0x11 - flash bitstream and 0x13 - ProgramData can you explain what each is for me please..

In particular how do you deal with unknown flash write lengths like code for STM32 or SOC that needs to be written to flash? (no operands for address and size)

[Folknology]

@lawrie what are you thoughts on @AndyCap 's idea above?

[AndyCap]

0x11 - flash bitstream expects the chip.bin bitstream to follow on the stream and programs it into the flash at address 0, this uses the same sort of code as the Ice40 program where the length is hard coded.

0x15 programs arbitrary data (say an arm binary) into the flash at an address, it expects a uint32_t to define the address, then another uint32_t to define the length, then the data. So: 7e aa 99 11 <address> <length> <b0>..<bn>

One thing to be aware of is that at least from a mac when you cat two files to send like:

cat flashBitstream.bin chip.bin > dev/blah

It doesn't really send the concatenated data, you will get one usb frame with the 8 bytes from flashBitstream.bin and then the subsequent usb frames will be chip.bin. So the stream handling needs to handle this.

Also there is a chance depending on what the user is sending that data items like uint32_t may straddle usb packets so the stream handling also needs to handle that as well.

[Folknology]

There is another possibility which is having a choice of 2 firmware images. The basic default version which BlackIce Mx ships with, supporting legacy and flash using mode button, or the alternative firmware with no legacy support just advanced wrapped uploads along with some supporting scripts or user software.

[AndyCap]

There would be some advantages of that approach.

Also something that needs thinking about is that with the current model the usb callback is only called when there is data, so if too little data is sent we get no timeout and if too much data is sent it spills over into the next run of stream processing.

If you had the alternative firmware and some simple command line software to sent stuff to the board then more attention could be given to some form of handshaking and general error checking.

[lawrie]

It doesn't really send the concatenated data, you will get one usb frame with the 8 bytes from flashBitstream.bin and then the subsequent usb frames will be chip.bin. So the stream handling needs to handle this

Yes, I found that it was like that on Linux too.

[AndyCap]

Also another thing that requires looking at is the cdc stuff going out of the board, as it stands there is no buffering of data and any subsequent call to cdc_puts()/CDC_Transmit_FS() within the same usb frame returns an error and you loose that data.

[AndyCap]

Yes, I found that it was like that on Linux too.

Must be a standard thing then, strange.