Port A and B disabled when modifying Port D/E on F207ZG

[Davorin]

Good afternoon (o;

Testing a GPIB code on my Nucleo-F207ZG board...

GPIB communication is just fine, which uses PORT D and Port E....

Now I added SPI code which reads out temperature from a MAX31855 device....

using PA5/6 for SPI and PA4 for chip select...

I can only read it out one time...and as soon the GPIB code modifies Port D/E direction,

I don't see any signals anymore on Port A....

For testing I added a HAL_GPIO_Toggle() statement in the main while loop...

but this also stops as soon PortD/E is modified....

Any ideas what is going wrong?

thanks in advance

richard

[Tesla DeLorean]

>>Any ideas what is going wrong?

a) Your code

b) External wiring/connectivity you've not taken account of

[waclawek.jan]

> as soon the GPIB code modifies Port D/E direction,

How?

And by that, I don't mean, which Cube/HAL function are you calling, but hint you to look at what does that code actually do. Cube/HAL is open source, you can debug it as part of your program.

JW

[Davorin]

Well it is already late here...have to get my sleep and look tomorrow (o;

Maybe the assembler output gives some more hints as I only use HAL_GPIO_Init for port D and E to swap direction...

and for individual pins GPIOD->ODR |= DAV_Pin for example...

Strange it affects port A and B when I changed SPI1 from PA to PB...

[Davorin]

Seems I've found it (o;

Well wasn't the wiring nor the code actually (o:;

Used SPI1 ind Receive Only Master Mode....which caused to send out always 48 clock cycles on first read, but the receiving buffer was set to 32 bits as the MAX31855 returns not more data...

On subsequent calls SPI1 sends correctly 32 clock cycles...but then I assume the previous 48 clock cycles read has overwritten some other location...causing the code to behave wrong...

Switched now to SPI2 in Full Master Mode and it always sends 32 clock cycles and returns correct data ;)

 This is my test setup btw (o;