[SOLVED]SPI.transfer of byte crashes F407VET6?

Discussions about the STM32generic core
User avatar
BennehBoy
Posts: 500
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

[SOLVED]SPI.transfer of byte crashes F407VET6?

Post by BennehBoy » Sun Jan 14, 2018 4:07 pm

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).

Code: Select all

// 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
Here's the code that results in a crash.... I've removed the other stuff that works but am happy to include all. SPI initialisation is taken care of by the adafruit SSD1306 library if you're wondering why I've not included any of that stuff.

Code: Select all

byte RegisterValues[] =    {0x90,  0x03,   0xFC,   0x7F,   0xC0,   0x7F,     0xFF,     0x80,     0x00,     0x00 };
String RegisterNames[] =   {"CR0", "CR1", "MASK", "CJHF", "CHLF", "LTHFTH", "LTHFTL", "LTLFTH", "LTLFTL", "CJTO"};
byte RegisterAddresses[] = {0x00,  0x01,   0x02,   0x03,   0x04,   0x04,     0x06,     0x07,     0x08,     0x09 };

void MAXInitializeChannel(int Pin) {
  for (int i = 0; i < NumRegisters; i++) {
    MAXWriteRegister(Pin, i, RegisterValues[i]);
  }
}

void setup()   {
  //start serial connection
  Serial.begin(9600);  //uncomment to send serial debug info

  // Pin setup
  pinMode (OLED_CS, OUTPUT);
  digitalWrite(OLED_CS, HIGH);
  pinMode (MAX_CS, OUTPUT);
  digitalWrite(MAX_CS, HIGH);
   
MAXInitializeChannel(MAX_CS); // Init the MAX31856   // HANGS HERE

}

void loop() {
//do some stuff
}


void MAXWriteRegister(int Pin, byte Register, byte Value) {
  byte Address = Register | 0x80; //Set bit 7 high for a write command
  SPI.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE3));
  digitalWrite(Pin, LOW);
  delayMicroseconds(1);
  SPI.transfer(Address);
  delayMicroseconds(1);
  SPI.transfer(Value);
  digitalWrite(Pin, HIGH);
  SPI.endTransaction();
}
One note is that the typing could be a bit stricter, I'll tighten that up and see if there's any change - wouldn't expect a vast difference between this on roger's core & a Maple Mini vs 407VET6 & STM32GENERIC though...
Last edited by BennehBoy on Thu Jan 25, 2018 10:14 am, edited 2 times in total.
-------------------------------------
https://github.com/BennehBoy

User avatar
BennehBoy
Posts: 500
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: SPI transactions crash F407VET6?

Post by BennehBoy » Sun Jan 14, 2018 4:19 pm

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

Code: Select all

  SPI.transfer(Address);
 
The STM32GERNERIC docs indicate this:
uint8_t transfer(uint8_t data);
Send a 8 bits on SPI, and return the received 8 bit data.
Are a byte and a uint8_t not interchangeable? Or is this because this implementation expects to also receive?

Sorry, these are probably fairly n00b questions.
-------------------------------------
https://github.com/BennehBoy

User avatar
BennehBoy
Posts: 500
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: SPI.transfer of byte crashes F407VET6?

Post by BennehBoy » Sun Jan 14, 2018 9:57 pm

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 :/
-------------------------------------
https://github.com/BennehBoy

User avatar
BennehBoy
Posts: 500
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: SPI.transfer of byte crashes F407VET6?

Post by BennehBoy » Mon Jan 15, 2018 2:21 pm

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.
-------------------------------------
https://github.com/BennehBoy

User avatar
Pito
Posts: 1729
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: SPI.transfer of byte crashes F407VET6?

Post by Pito » Mon Jan 15, 2018 2:44 pm

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..
Pukao Hats Cleaning Services Ltd.

stevestrong
Posts: 2043
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany
Contact:

Re: SPI.transfer of byte crashes F407VET6?

Post by stevestrong » Mon Jan 15, 2018 2:47 pm

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.

User avatar
BennehBoy
Posts: 500
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: SPI.transfer of byte crashes F407VET6?

Post by BennehBoy » Mon Jan 15, 2018 2:55 pm

stevestrong wrote:
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 :D
-------------------------------------
https://github.com/BennehBoy

User avatar
BennehBoy
Posts: 500
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: SPI.transfer of byte crashes F407VET6?

Post by BennehBoy » Mon Jan 15, 2018 3:05 pm

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.
-------------------------------------
https://github.com/BennehBoy

User avatar
BennehBoy
Posts: 500
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: SPI.transfer of byte crashes F407VET6?

Post by BennehBoy » Mon Jan 15, 2018 3:14 pm

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... :D
-------------------------------------
https://github.com/BennehBoy

stevestrong
Posts: 2043
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany
Contact:

Re: SPI.transfer of byte crashes F407VET6?

Post by stevestrong » Mon Jan 15, 2018 3:17 pm

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.

Post Reply