Author Topic: 32F417 SPI running at one third the speed it should  (Read 8234 times)

0 Members and 1 Guest are viewing this topic.

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8110
  • Country: fi
Re: 32F417 SPI running at one third the speed it should
« Reply #75 on: February 03, 2022, 05:51:31 pm »
Hmmm... I have NRST unconnected too. Didn't put a cap on it because the debugger drives it. But presumably 10nF should be safe?

Given it has a ~40k pullup, one would need a fairly powerful radiated spike to pull it down for long enough. This is the data sheet, showing 100nF

The very point of my post was, the reference manual, where this information does not belong at all, gives completely different rationale for the capacitor: it is Just Needed. They don't give the exact reason, but at least H743 with external Vcore* fails to start without the capacitor, and it has nothing to do with EMI or radiated anything, the test environment was quiet and I probed that pin to verify clean signal - rising fast, though, as expected without the cap. The CPU clearly needs the slow ramp on the pin, lengthening the internally generated power-on reset pulse.

*) I'm mentioning this because it could be important, even though the thing should boot with internal LDO regardless, but maybe there is some weird power sequencing thing going on. In any case, the capacitor is needed per the reference manual, and not needed per the datasheet. That's the point. You have to read all the documentation carefully.

It's actually quite classical to somehow f*** up the internal reset circuitry. Early AVR devices were known to have issues to the point people designing in external power-on-reset driver ICs. Later AVRs supposedly fixed it, but still required smaller external pull-up and some official programmers denied working if they did not detect the correct amount of resistance.
« Last Edit: February 03, 2022, 05:55:22 pm by Siwastaja »
 
The following users thanked this post: AndyC_772

Online harerod

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: de
  • ee - digital & analog
    • My services:
Re: 32F417 SPI running at one third the speed it should
« Reply #76 on: February 03, 2022, 06:14:08 pm »
The attached STM32H743 excerpt from the datasheet might shed some light on  Siwastaja's NRST mystery: "6.3.16 NRST pin characteristics"
Not only does it give the "Figure 23. Recommended NRST pin protection", it also gives the "Table 65. NRST pin characteristics", which include timings. I would just assume that a pin without cappa and excellent layout (e.g. no pin loading at all) might actually violate these requirements.
However - peter-h wrangles the venerable STM32F417. The NRST is described in the datasheet under "NRST pin characteristics". Minor differences, only.
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: 32F417 SPI running at one third the speed it should
« Reply #77 on: February 03, 2022, 06:22:18 pm »
The very point of my post was, the reference manual, where this information does not belong at all, gives completely different rationale for the capacitor: it is Just Needed. They don't give the exact reason, but at least H743 with external Vcore* fails to start without the capacitor

Thank you for sharing this observation, you've probably just saved me hours of head scratching.

I've just completed a prototype using the STM32H723, my first design with an H7 device. Like the part you're using, there's nothing about needing a capacitor in the data sheet, but it's prescribed in the full Reference Manual. Fortunately I can solder one easily across the back of the debug connector, where NRST and GND appear adjacent to each other. Glad I went for the full size 0.1" header this time...!

Fig. 43 (page 309) shows a simple block diagram of the reset circuit, including a 20us pulse generator which drives the NRST pin. This block has inputs 'pwr_bor_rst' and 'pwr_por_rst', which imply that the device should generate its own nice, clean 20us reset pulse following power-up or a brown-out.

I wonder whether perhaps this pulse generator simply doesn't work, or at least, doesn't work properly at power-up?

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8110
  • Country: fi
Re: 32F417 SPI running at one third the speed it should
« Reply #78 on: February 03, 2022, 06:32:20 pm »
I wonder whether perhaps this pulse generator simply doesn't work, or at least, doesn't work properly at power-up?

My take is, it generates a pulse that is too short, or does it too early. This pulse is exposed on the pin, so adding C creates a simple RC delay with the internal pull-up.

Protection against noise and ESD are additional benefits, but clearly not the actual reason why it's needed.

I also scoped my supplies and they were increasing nicely and monotonically. Internal POR circuit should have no difficulties...

Obviously nobody will follow that "recommended circuit" of the datasheet, because it includes a pushbutton, and 99% of the products do not use reset buttons, except devboards. And in that "recommendation", the capacitor is grouped with the mechanical switch, clearly indicating they belong together, making people easily ignore the capacitor.
« Last Edit: February 03, 2022, 06:34:20 pm by Siwastaja »
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3671
  • Country: gb
  • Doing electronics since the 1960s...
Re: 32F417 SPI running at one third the speed it should
« Reply #79 on: February 03, 2022, 06:36:43 pm »
Quote
H743 with external Vcore* fails to start without the capacitor,

It won't be due to the slower risetime enabling a start. It will be because it starts up, the HS oscillator starts up, and then it samples NRST, and if it is HIGH then it bombs. So the cap is needed for a delay. Or it may just need a delay on NRST after VCC rises.

I am not surprised they screwed this up. NRST will have a messy rise; all you need is a non monotonic VCC rise and the hardware will see a "pulse" on NRST.

Historically a reset without a "supervisor" has simply not worked. I have for many years used the Seiko S808
https://eu.mouser.com/ProductDetail/ABLIC/S-80825CNMC-B8KT2G?qs=1uru1TqDsKB%2FV9OyZye9RA%3D%3D
with Atmel 90S1200 AVR and other chips. For the Hitachi H8/3xx I have used the Maxim MAX706 but have just designed out those scammers and put in the ST version
https://eu.mouser.com/ProductDetail/STMicroelectronics/STM706M6F?qs=QRsLLuHQazBglYFCH0NTIg%3D%3D

I am just about to populate 10 boards and will fit the 10nF on all, then change the design to add this.

The pushbutton is optional, but it is dumb because it will bounce around. The 417 data sheet says it will reject <100ns pulses and will accept >300ns pulses. A switch will not do either :) If I really had a button I would put in a schmitt trigger to feed NRST (and made the cap TC a lot longer; say 100ms).
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
Re: 32F417 SPI running at one third the speed it should
« Reply #80 on: February 03, 2022, 07:39:27 pm »
Code: [Select]
SPI2->DR;
SPI2->SR;

which someone here told me does a read of that register(s). Well, it does not

It definitely does, unless you have written your own header which fails to qualify SPI2 as volatile, or use a broken compiler.
This is interesting. It is the first time I ever see this mentioned. I just checked with GCC 4.6.2; the statement does perform a read but it does not result in less instructions compared to reading a value into a dummy variable (either optimised for size or speed ). That makes sense because in the end the data that is read must end up in a register even if it isn't used. I do get a warning from the IDE that it is a statement without effect though.
This was changed reasonably recently (maybe even in gcc 10).  If you have a volatile variable on the stack now the compiler guarantees it occupies space on the stack throughout its entire formal scope, and all accesses to the stack slot become barriers.
 

Online harerod

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: de
  • ee - digital & analog
    • My services:
Re: 32F417 SPI running at one third the speed it should
« Reply #81 on: February 04, 2022, 09:00:00 am »
...This was changed reasonably recently (maybe even in gcc 10).  If you have a volatile variable on the stack now the compiler guarantees it occupies space on the stack throughout its entire formal scope, and all accesses to the stack slot become barriers.
Thanks for the heads-up.
STM32CubeIDE release v1.8.0 RN0114 states
GNU Tools for STM32, based on GNU Tools for Arm Embedded Processors 9-2020-q2-update 9.3.1 20200408 (release)
So most discussions for STM32 would be about GCC 9.x
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3671
  • Country: gb
  • Doing electronics since the 1960s...
Re: 32F417 SPI running at one third the speed it should
« Reply #82 on: February 04, 2022, 10:08:13 am »
Yes; current Cube, v1.8.0, comes with the above v9.x compiler. I checked it myself, compiling and checking the binary matches byte for byte. I also checked the version which is output when invoking the exe from a command line.

It's been at that version for a long time.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
Re: 32F417 SPI running at one third the speed it should
« Reply #83 on: February 04, 2022, 05:02:16 pm »
...This was changed reasonably recently (maybe even in gcc 10).  If you have a volatile variable on the stack now the compiler guarantees it occupies space on the stack throughout its entire formal scope, and all accesses to the stack slot become barriers.
Thanks for the heads-up.
STM32CubeIDE release v1.8.0 RN0114 states
GNU Tools for STM32, based on GNU Tools for Arm Embedded Processors 9-2020-q2-update 9.3.1 20200408 (release)
So most discussions for STM32 would be about GCC 9.x
That's not necessarily true.  I don't use their IDE and I use the toolchains provided by ARM:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
 

Offline keremsur

  • Newbie
  • Posts: 1
  • Country: cm
Re: 32F417 SPI running at one third the speed it should
« Reply #84 on: April 06, 2022, 09:10:52 am »
How can one use SPI in a 16-bit mode? Do you mean actually setting SPI to 16 bits so that it is shifting out, and shifting in, a 16 bit value at a time?

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: 32F417 SPI running at one third the speed it should
« Reply #85 on: April 06, 2022, 10:31:45 am »
It depends on the device. Usually there's a register you can program to set the word length.

One interesting feature on some of the STM32 devices is that the SPI transmit register supports 'packing'.

What this means, is that if your code performs a 16-bit write to it, then 16 bits get clocked out. If, however, your code performs an 8-bit write, then only 8 bits are sent.

The register is usually defined in the header as 16 bits wide, because it is. This leads to an infuriating symptom, where you write:

Code: [Select]
uint8_t d;
SPI_DR = d;
... and wonder why the SPI port sends twice as many bits as it should, and every other byte is zero. Instead you must write:

Code: [Select]
uint8_t *spi_dr_8bit = (uint8_t*) &SPI_DR;
uint8_t d;
*spi_dr_8bit = d;
...since this explicitly performs an 8 bit write, as opposed to a write of an 8 bit value to a 16 bit register.

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3671
  • Country: gb
  • Doing electronics since the 1960s...
Re: 32F417 SPI running at one third the speed it should
« Reply #86 on: April 06, 2022, 11:54:21 am »
Yes the 32F417 SPI can do 8 bits or 16 bits.

The byte order is not configurable for the 16 bit mode however and in some applications one has to swap the two bytes in software.

The 16 bit mode does no more than sending 2 bytes in the 8 bit mode, but at least you know the 16 bits will come out without any gaps if there are interrupts etc. It also supports some code optimisation if one is polling SPI and running at high bit rates. The 32F4 peripherals are not as fast as you might expect from a 168MHz CPU; they run at say 42MHz and a lot of stuff takes several clocks, so polled implementations run surprisingly slowly, with gaps. See this thread further back.

DMA is the best way and then the 16 bit mode is generally not needed.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf