ChibiOS Free Embedded RTOS

Your project includes "board files": board.c and board.h

Those files are generated from an XML description file board.chcfg which contains all the values to be programmed in GPIO.

There is a guide here: https://www.youtube.com/watch?v=HwJqZfITvV0

Alternate function tables are found in the STM32 Data Sheet.

Giovanni

Giovanni wrote:Your project includes "board files": board.c and board.h

Those files are generated from an XML description file board.chcfg which contains all the values to be programmed in GPIO.

There is a guide here: https://www.youtube.com/watch?v=HwJqZfITvV0

Alternate function tables are found in the STM32 Data Sheet.

Giovanni

Thanks, I have made some progress on this - I at least have clocks and data output looking sane, however the chip select is all over the place - bouncing up and down while the data is going out. I notice in the two examples that the two pin configurations are very different. Do you know what the correct pin configurations would be for an H7 (e.g. PULLUP vs FLOATING) or is this dependent on the memory chip involved?

If your board has external pullups then floating, else internal pullups.

Giovanni

Giovanni wrote:If your board has external pullups then floating, else internal pullups.

Giovanni

Thanks - I'm sending all the right things but not a peep out of the flash chip. Any suggestions? I have ordered a different breakout in case I have a dud.

Hi,

I would rate this thing "hard".

You need to check carefully the sequences sent to the memory, the code enforcing a reset state (hard to get right), the switch to the full N-wires mode, SDR and DDR modes, number of dummy cycles, and lots of other details. Those chips, except for a basic read command, are very dissimilar from each other.

Forget DDR transfers, at least initially, use the simplest commands if multiple variants are provided.

If you started from an existing mini driver then you need to verify everything, don't assume anything would just work. it is not much code but it is hard to get it right. All settings you see in the driver are 100% dependent on the device.

A logic analyser could help, an oscilloscope not so much. Initially just try to perform a simple "status register read" and get something out of the device.

Easy approach: get one for the devices already supported and practice using that.

Giovanni

Giovanni wrote:Hi,

I would rate this thing "hard".

You need to check carefully the sequences sent to the memory, the code enforcing a reset state (hard to get right), the switch to the full N-wires mode, SDR and DDR modes, number of dummy cycles, and lots of other details. Those chips, except for a basic read command, are very dissimilar from each other.

Forget DDR transfers, at least initially, use the simplest commands if multiple variants are provided.

If you started from an existing mini driver then you need to verify everything, don't assume anything would just work. it is not much code but it is hard to get it right. All settings you see in the driver are 100% dependent on the device.

A logic analyser could help, an oscilloscope not so much. Initially just try to perform a simple "status register read" and get something out of the device.

Easy approach: get one for the devices already supported and practice using that.

Giovanni

Thanks - yeah I have a logic analyzer and am using that to verify the signals - I would send a picture but this forum software is a PITA to do that (does this work? )
I have the chip spec and am verifying everything that I need, it all looks correct. I am running at 2Mhz to get good data from the LA. I have tried with reset and without but I never get anything back on IO1. Incidentally this is using QUADSPIv2 - there are no examples using that, presumably you have tried it?

Looked like the picture worked - this is me sending a read register command

If the command comes out of the MCU then the driver is working, it is the memory that does not respond for some reason.

Giovanni

So I'm back on this. I bought a DevEBox https://github.com/mcauser/MCUDEV_DEVEBOX_H7XX_M which was a much simpler way of getting an external flash development board, and thanks to some great work by a colleague we have external flash working and the autopilot running in external flash.

There is obviously a performance penalty with external flash and so we are putting various highly used functions in RAM, particularly ITCM RAM. I am told there is a cost for switching between RAM and external flash and so in some circumstances its better to leave things in external flash.

Giovanni I am wondering whether you have any recommendations on what things should go in RAM and whether the type of RAM makes any difference. Currently we have put the whole of chibios in RAM together with ISR functions.

Hi,

I would put in RAM the RT kernel, the OSAL and your ISRs, the rest is to be evaluated case by case, probably some specific drivers.

Giovanni

Giovanni wrote:Hi,

I would put in RAM the RT kernel, the OSAL and your ISRs, the rest is to be evaluated case by case, probably some specific drivers.

Giovanni

Thanks - is there a way of easily identifying these for the linker script?