IceCore myStorm firmware

[Folknology]

OK so I have the beginnings of a new IceCore 'myStorm' firmware. Please only use this if you can compile and build the firmware, it is development only preview at this stage for those interested in development and a lot can go wrong with it..

Here are some key points about the new myStorm firmware:

• There is currently no documentation and the code itself is still to be documented, However I am here to answer questions.

• I am moving things to C++ in order to wrap and abstract functionality better, the ST HAL is a difficult environment unless you already know it..

• There are a number of different features we need to work on, one of which is USB/Uart coms another is programming including the flash, that's where I have begun..

• I am rapidly coming to the conclusion that the ST HAL sucks big time in certain areas, I have had major issues with the USB parts and have had to compromise temporarily until I find a way around some issues. It seems to be impossible right now to do TX and RX over USB to and from Uart at the same time without internal HAL buffers being polluted by each other, WTF..?
  This is very frustrating for me, but in order to move things forward I am suppressing PC USB Host to Ice40 Uart coms until I can find a way of either fixing or bypassing the ST HAL issues. This means that the Ice40 can send over Uart and the firmware will buffer this to the Host, but not the other way around.

• You can still program the Ice40 and this part of the firmware has been re-written with the future changes in mind.

• We will be able to program the flash directly (eventually) despite the USB HAL issues above, we just need to get that code done, there is an example of communicating with the flash to retrieve it's ID included for those interested in pursuing this, any help gratefully received...

Having said all of that please take a look and provide me with feedback about bugs, errors issues and or suggestions and ideas moving forward.

[lawrie]

I have had major issues with the USB parts and have had to compromise temporarily until I find a way around some issues. It seems to be impossible right now to do TX and RX over USB to and from Uart at the same time without internal HAL buffers being polluted by each other, WTF..?

Did you look at this project - https://github.com/ayushgaud/USB_Serial_Bridge

It purports to implement a USB to Uart bridge using the STM32 HAL. When I looked at it a while ago, it seemed to use DMA on the uart TX side and interrupts for the RX side.

[Folknology]

Yes I have seen this a while back, I am using a similar setup, however I still get the same issues.

Basically what happens is when I issue 'CDC_Transmit_FS' to send something up USB to the host, my 'usbcdc_rxcallback' gets called with what was sent (or corrupted versions of it). Even worse if one runs some sort of echo test on the Ice40 it ends in an infinite buffer loop of chars..

[lawrie]

Basically what happens is when I issue 'CDC_Transmit_FS' to send something up USB to the host, my 'usbcdc_rxcallback' gets called with what was sent

A bit unlikely, but your problem couldn't be the host doing an echo, which could be fixed by "stty .. -echo" could it? I had that problem with Tom Verbeure's uart_loopback program when I first ran it - see https://forum.mystorm.uk/t/verilog-code-from-simon-monks-book-programming-fpgas/382/9

[lawrie]

Please only use this if you can compile and build the firmware,

I am having problems building that very of the firmware when I do "make clean" followed by "make raw". I get no mystorm.raw file and I get these errors:

arm-none-eabi-gcc: error: output/obj/usbd_cdc_if.o: No such file or directory
arm-none-eabi-gcc: error: output/obj/usbd_conf.o: No such file or directory
arm-none-eabi-gcc: error: output/obj/usbd_desc.o: No such file or directory
arm-none-eabi-gcc: error: output/obj/usb_device.o: No such file or directory
arm-none-eabi-gcc: error: output/obj/stm32f7xx_it.o: No such file or directory
arm-none-eabi-gcc: error: output/obj/stm32f7xx_hal_msp.o: No such file or directory
make: *** [makefile:120: output/mystorm.elf] Error 1

It looks like the makefile still includes source that it no longer used.

[Folknology]

Are you in the mystorm directory?

[lawrie]

Yes. In the USB-CDC-issue-3 branch.

[Folknology]

OK I just downloaded it from the repo to try, I get the same issue, trying to work out what I broke on commit..

OK thats weird I have those missing object files (in my current dir not the git clone) in my output/obj dir but they are several days old..

[Folknology]

OK I copied the Src .c files into mystorm dir it seems to build properly now I must have an error in my makefile, if anyone can work it out please let me know! I committed the changes it should build for you now @lawrie

[Folknology]

A bit unlikely, but your problem couldn't be the host doing an echo, which could be fixed by "stty .. -echo" could it? I had that problem with Tom Verbeure's uart_loopback program when I first ran it - see https://forum.mystorm.uk/t/verilog-code-from-simon-monks-book-programming-fpgas/382/9

How about very likely, doh! I had forgotten all about the default echo!! I have just re-enabled it in the source and commited so it now also does PC->USB->Uart->Ice40 using DMA..

Thanks @lawrie

Is it working for you now BTW?

[lawrie]

Is it working for you now BTW?

Not yet. I am now getting:

/home/lawrie/arm-gcc/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: output/drivers.a(stm32f7xx_hal_timebase_tim_template.o): in function `HAL_TIM_PeriodElapsedCallback':
/home/lawrie/IceCore/firmware/myStorm/../Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_timebase_tim_template.c:162: multiple definition of `HAL_TIM_PeriodElapsedCallback'; output/obj/mystorm.o:/home/lawrie/IceCore/firmware/myStorm/mystorm.cpp:344: first defined here
/home/lawrie/arm-gcc/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: output/drivers.a(stm32f7xx_hal_timebase_tim_template.o): in function `TIM6_DAC_IRQHandler':
/home/lawrie/IceCore/firmware/myStorm/../Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_timebase_tim_template.c:171: multiple definition of `TIM6_DAC_IRQHandler'; output/obj/stm32f7xx_it.o:/home/lawrie/IceCore/firmware/myStorm/stm32f7xx_it.c:240: first defined here
collect2: error: ld returned 1 exit status
make: *** [makefile:120: output/mystorm.elf] Error 1

[Folknology]

try removing
../Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_timebase_tim_template.c

This is just one of many CubeMx annoyances, it sometimes dumps these template files into the build which are not required..

I just pushed the change that removes this one..

Does it build now and run on your system?

[lawrie]

Does it build now and run on your system?

Yes, it builds fine now.

I haven't tried running it yet, for a couple of reasons. One is that I am building on my VirtualBox Ubuntu machine, but running on a native Linux box, so I am using a fork of your repository to pick up the new version of the firmware.

The other reason is that I want the small change I made to default the CST, HOLD and WP pins high so that boot from flash memory works.

My convoluted reason for that is that the main reason I want your new firmware is so that I can use the user USB port rather than an external USB to uart device. And the main program I want to run is one that uses XIP from flash memory, such as Zephyr OS programs. But SpinalHDL XIP only works if I load the bitstream from flash. That is because it does not send the 0xab to the flash memory, and it is rather hard for me to change the SpinalHDL library XIP module. It works if you load the bitstream from flash and use the -s option on icepack, as that means that the ice40 SPI master wakes up the flash and then leaves it powered up.

So I will make my change to the firmware before I use it.

[Folknology]

The other reason is that I want the small change I made to default the CST, HOLD and WP pins high so that boot from flash memory works.

Ok please note I have changed the Ice40_SPI_CS pin to be open drain in this version and after programming it should release to the external resistor pullup and thus not interfere with the Ice40 driving it. I did this to avoid having to initiase and reinitialise the GPIO CS pin every time I used it! Also after programming, it frees & releases flash so they should be high, I am assuming you are not driving these pins from Spinal?

[lawrie]

I am assuming you are not driving these pins from Spinal?

No, I don't use WP and HOLD from SaxonSoc, just SS, SCLK, MOSI and MISO.

But your change won't help me boot from flash, as I can only do that from power-on until you add the flash programming capability to the firmware. I currently have to unplug the programming USB and plug it back in again to boot into my (multi-boot) flash image at address 0. I can't even use SB_WARMBOOT to boot into it, as that only works from a bitstream which has been booted from flash.

[Folknology]

But your change won't help me boot from flash, as I can only do that from power-on until you add the flash programming capability to the firmware. I currently have to unplug the programming USB and plug it back in again to boot into my (multi-boot) flash image at address 0. I can't even use SB_WARMBOOT to boot into it, as that only works from a bitstream which has been booted from flash.

If you look at the code, flashbooting is implemented as part of Fpga::reset(bit_src), however it is also completely untested, take a look and let me know your thoughts, try it even..

[Folknology]

Does the firmware I need to issue a wakeup command or does the Ice40 do that automatically?

[lawrie]

Does the firmware I need to issue a wakeup command or does the Ice40 do that automatically?

The ice40 does it automatically when it acts as an SPI master to the flash memory.

[lawrie]

Does it build now and run on your system?

I am not having much luck running it at the moment.

The version I built does not create /dev/ttyACM0 even if I build it with no changes at all.

The version of mystorm.raw in the repository does create /dev/ttyACM0, but I don't see a device for the USB to uart. How does it appear on your system. Is it /dev/ttyUSB0, or /dev/ttyACM1, or something else?

[Folknology]

The version I built does not create /dev/ttyACM0 even if I build it with no changes at all.

The version of mystorm.raw currently does create /dev/ttyACM0, but I don't see a device for the USB to uart. How does it appear on your system. Is it /dev/ttyUSB0, or /dev/ttyACM1, or something else?

It should appear as /dev/ttyACM0 i.e. the same as the programming device (it's the same usb device!).

Check in the usbd_conf.h files there should be one in the mystorm directory and one in the Inc dir. They should both have :

#define USBD_malloc (uint32_t *)USBD_static_malloc

on line 125, if the one in Inc dir doesn't then cp the one from the mystorm dir to replace it (damm cubemx, replacing my sh*t)..