Skip to main content
Mikk Leini
Mikk Leini
Senior
February 24, 2015
Question

PMSM FOC code stuck

  • February 24, 2015
  • 4 replies
  • 887 views
Posted on February 24, 2015 at 18:30

I have a custom motor controller board with STM32F303RB. I took the STM32 PMSM FOC Lib 4.0 project for STM3230x as basis for code. I only generated new motor configuration with MC studio and replaced evaluation board code with my board code.

The problem is that code stucks. I can trace the C function call to SPD_Init(oSpeedSensor[M1]) and in disassembly debugging mode i can see that eventually PC jumps to address 0x00000000 and next stepping jumps onto address 0xF83CF000. And it will be stuck there forever. That area is Cortex-M4 internal peripherals area which should be vendor specific?

I also tried different configurations - basically removed all features and it's still the same. 

Can somebody help me with this?

I'm using Keil uVision 5.13 Lite.

#pmsm-foc-stm32f3-stuck
This topic has been closed for replies.

4 replies

Mikk Leini
Mikk LeiniAuthor
Senior
March 7, 2015
Posted on March 07, 2015 at 22:57

I'm still trying to get it working...

I did one test:

I took STM32F30x_Workspace example, compiled it with MDK-ARM 5.0.5 (has same compiler version as PMSM FOC library) and ran it on STM32F3 discovery board. It didn't stuck - program reached the main loop.

Then i upgraded to MDK-ARM 5.14 and the code stopped working (it stucks at CPU ''internal area''). So then i downgraded to 5.0.5 and as a surprise the code still stucked.

While discovery board was working i also ran same code on my board. I tracked the both assembly codes to the point where FOC library used CRC peripheral but on my board the result was zero so some branch instruction jumped to address zero (as i wrote in previous post). I can't figure out what is done with CRC in the library. I've look at map file to see if there's some special area which is calculated but nothing spurious....

Now when none of the boards are working i see that after the program jumps to strange area then the ''Fault report'' window of u-Vision tells that there's a Memory Manage fault (IACCVIOL) and Bus fault (IBUSERR). Strangely, the interrupt handlers for these faults aren't called.

This is driving my crazy. I don't know what to suspect anymore - is it library & linker incompatibility, MCU incomptability, the HW (some IO condition?).

F3 has also some special 8 kB CCMRAM of which very little is written about. I've checked the errata also and there's some SRAM access issue but it should have workaround on good compiler...

Tesla DeLorean
Tesla DeLorean
Guru
March 7, 2015
Posted on March 08, 2015 at 00:55

The STemWin library uses the CRC peripheral to validate the silicon in use is an ST part, related to how the software was licensed from Segger. In this case you have to enable the CRC peripheral clock before initializing the library.

The address of the CRC peripheral in the APB/AHB space is probably different on the F1 vs F3.

The CCM memory, is the Tightly Coupled Memory, on the F4 this only has data connectivity, and can't run code. On the F3 it has connectivity on the instruction side, so can run code out of zero wait state memory. Flash is slow, nominally a 35-42ns access time regardless of how fast the processor clocks. On the F2/F4 the ART caches very wide Flash lines (128-bit ?), and can deliver cache hits to the prefetch of the CPU faster than the cycle time for internal SRAM. It's quite effective, and while performance is somewhat more variable, it doesn't make sense to copy code to RAM to run it faster.

CCM is nominally at 0x10000000, and does not support DMA or bit-banding.
Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Mikk Leini
Mikk LeiniAuthor
Senior
March 8, 2015
Posted on March 08, 2015 at 21:57

Hi,

I enabled CRC peripheral, it didn't help.

I also built with all CCMRAM macros and area disabled. Same result.

Then i tried IAR EW ARM and PMSM FOC STM32F30x example. It also stucked on some strange memory address after entering  PWMC_Init(oCurrSensor[M2]).

Interestingly - IAR has nice feature - auto step. So i let it automatically step assembly instructions and see how far it goes. And it goes much far when just letting it run to some breakpoint. That makes me believe there's some interrupt issue or something.

Mikk Leini
Mikk LeiniAuthor
Senior
March 10, 2015
Posted on March 10, 2015 at 22:16

I found the reason why the custom board code stucked. One current sensor initialization code was commented out :( and it probably caused some kind of null pointer issue for library (that would explain why it jumped to address zero).

But i still don't completely understand why the example project stucks on the F3 discovery board (MCU is the same). My best guess is - i'm using free 32KB version and the original code compiles to 33KB. So to make it fit i uncheck the ''Optimize for time''. I suspect that such optimization doesn't match with library. However, my custom code works with and without time optimization so this explanation is not completely correct.

This is another topic, but i'll say it just in case if somebody faces similar problem.

Seems like the FOC doesn't support multiple ADC's. For example when sample shunts with ADC3/4 and sample VBUS and Temp with ADC1/2. I see that it tries to initialize the ADC1 peripheral but it doesn't enable the AHB clock to ADC1/2. So to get it working, enable the AHB clock on your own before MCBoot.

Edit:

Found another problem which explains CRC peripheral issue. My project had wrong system_stm32f3xx.c file - it was from newer peripheral library, but it turned out PMSM examples had a custom one which locates vector table (VTOR register) to CCMRAM area and also enable CRC peripheral clock. So that's why the CRC gave wrong answer and that's why interrupts jumped to weird places.

Terms & ConditionsAccessibility statement