[SOLVED]SPI.transfer of byte crashes F407VET6?

Today I spent some time porting a very cut down version of my car gauge system to a Black F407VET6 board that I have.

I’ve managed to get SPI communication to an SSD1306 working fine and can draw gfx, display fonts etc to it.

I have some custom code that will initialise a MAX31856 SPI temp sensor, and although this works fine on a Maple Mini using Rogers core, it hangs when run against STM32GENERIC.

Now I assume this is most likely to be me doing something silly, so I’ve included the code below.

The hang occurs irrespective of whether the MAX device is wired up or not. To rule out some issue with the code failing with the device being absent I removed the device on my Maple implementation and it does not crash there.

Any pointers?

definitions (the OLED & MAX are sharing the same bus).

// HW SPI
#define OLED_MOSI PA7 //4 // SPI_MOSI
#define MAX_MISO PA6 //5 // SPI MISO
#define OLED_CLK PA5 //6 // SPI_SCK
#define MAX_CS PB10 //7

#define NumRegisters 10


Some diag with serial output indicates that it hangs at the point of the first SPI.transfer

SPI.transfer(Address);


Full code is here -> https://github.com/BennehBoy/LRduino—F407VET6

Uncomment line 83 in the .ino to exhibit the hang.

I’m also having fun getting sdfat to work :/

Well it appears that the Adafruit SSD1306 library does not play nicely with SPI transactions. Why in conjunction with another device on the same bus using transactions this should work on Rogers core but not on STM32GENERIC is beyond me.

I’ll try driving the device on a second bus to see what happens… I tried forcing the library to use transactions but I think the init sequence timing breaks due to the way it’s been written so would have to do a lot of mucking about to make it work. – ie not worth it.

SPI transactions are the most simple you may imagine. It just clocks out 8 bits and reads 8 bits in. That is all.
The only issues I can imagine with using SPI with two or more different chips hanging on it:
1. wrong chip selects manipulation (you activate both chips during a transaction)
2. the chips have got different max SPI clock speeds, you do not change the clock speeds properly when accessing the chips
3. the chips have got different SPI clock edges modes (4 modes do exist)
4. the wires are too long, you have to provide some impedance matching..

Well, if it is working with Roger’s core, why not use it?
By preference, you could also try my repo, it is a bit further developed regarding F4.

[stevestrong – Mon Jan 15, 2018 2:47 pm] –
Well, if it is working with Roger’s core, why not use it?

It works with Roger’s Core on a Maple Mini, I’m trying to get this working on a Black F407VET6. I’ll give both Roger’s and your core a try against the 407 to see how they fare.

Regarding the problem, it’s not just a case of the code continues to run but the expected function fails, the 407 locks hard, so I think there’s an unhandled exception somewhere, eithe in core, or my code. I’m struggling to make any headway though

Both Adafruit libraries (SSD1306 & GFX) need reworking to function on Rogers core for Generic F407VE – no Wire.h or wiring_private.h (Not that wire is needed! And I’m lazy)

Fingers crossed for Stevestrongs.

No wiring_private in yours, commented it out and get a load of macros exceptions thrown.

Compiles and uploads but there’s no SPI or Serial output from the 407 – although I expect I may need to ensure that the GPIO definitions are correct.

…losing the will to live…

Here can you see what is supposed to run on my libmaple F4 core: http://stm32duino.com/viewtopic.php?f=39&t=1976
(I2C was also implemented on the generic F4 mini, which should run on the black F4, too).

Which macros throw exceptions?

P.S: The standard SPI port instantiated on F4 is SPI3.
And Serial is always USB serial, Serial 1 is always UART 1, etc.

TBH this is probably too much of a rabbit hole – I’ll likely abandon using the 407.

I was able to get the MAX31856 working on a separate SPI channel to my OLED.

I’d love to know what exactly crashes the core (STM32GENERIC – Daniel’s) when attempting to use transactions of differing modes/speeds on the same bus in rapid succession.

Now to make SDIO work…

So it looks like not all SD cards are compatible, an old card I was using just fine with a SPI reader didn’t work with the VET6, tried another card and now have working SDIO.