cancel
Showing results for 
Search instead for 
Did you mean: 

Port SPN3 motor-control examples to DK2?

karlchansen
Associate II

We are considering using a combination of the stm32mp157 and several powerSTEP01 devices in a system with multiple stepper-motors.

The X-NUCLEO-IHM03A1 plugs into the -DK2 just fine, but the SPN3 examples only work on the F0xx, F3xx, F4xx, and L0xx series.

Attempts to port one of the examples to the stm32mp157C-DK2 have not worked.

  1. Where can we get information on porting one platform's (e.g. F4xx) "arduino-style" connector to the stm32mp157C-DK2 "arduino-style" connector?
  2. Has anyone ported other code from the F0/F3/F4/L0 that uses the "arduino-style" connector onto the connector on the stm32mp157C-DK2?
    1. If so, can the code be shared, or the process documented?

We are approaching the GO/NOGO point of using the stm32mp1 and the powerSTEP01. Time is critical on this.

12 REPLIES 12
Olivier GALLIEN
ST Employee

Hi @karlchansen​ 

Please have a look to https://wiki.st.com/stm32mpu/wiki/IKS01A2_MEMS_expansion_board exposing one arduino style expansion board integration with DK2.

I will have a further look to X-NUCLEO-IHM03A1 integration.

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Olivier GALLIEN
ST Employee

Hi @karlchansen​ 

>> Attempts to port one of the examples to the stm32mp157C-DK2 have not worked.

Please confirm you simply manage to get it work on the M4 coprocessor ?

Did you test using "engineering" boot mode (A7 on Hold / M4 standalone) or in Production mode ( A7 Linux booted and driving M4 execution ) ?

Could you please be more specific when you said "not worked" ? Did you try debug/investigate with SW4STM32 ?

Thanks,

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
karlchansen
Associate II

Not working yet. I will look at the MEMS example.

We are working in Production mode.

For "not working":

  1. None of the SPN3 examples use settings compatible with the MP1. The examples are for the F0, F3, F4, and L0 devices, and on those boards the arduino pins are mapped to different GPIO and ports than on the MP1 pins. Also, different timers are used so it is unclear what timers should be used.
  2. We are using the Cube IDE for debugging. Attempts to debug SPN3 examples using SW4STM32 have completely failed. Unable to launch, unable to connect to app. Nothing with SW4STM32 debugging has worked.
  3. We are able to run the Cube IDE debugger, with some issues:
    1. Only the "ST-Link OpenOCD" mode seems to work. Attempts to use the "ST-Link GDB Server" mode give an error about ST-Link not found.
    2. Setting breakpoints that should stop the system as it starts up is not working. The breakpoints are never triggered.
      1. If we create a loop that runs 1000000 times, and set a breakpoint inside the loop, the breakpoint EVENTUALLY triggers, but the loop counter is typically over 400000 before the breakpoint triggers.
      2. Once the first breakpoint triggers, all subsequent breakpoints trigger.
    3. Trying to restart a debug session goes into an infinite-loop exception handler. We have to hard-reset the MP1 in order to run another debug session. The stack trace is:
SPI_FullDuplex_ComIT_Master_CM4 Debug [STM32 Cortex-M C/C++ Application]	
	SPI_FullDuplex_ComIT_Master_CM4.elf [cores: 2]	
		Thread #1 [main] 1 [core: 2] (Suspended : Signal : 0:Signal 0)	
			HAL_TIM_PWM_PulseFinishedCallback() at stm32mp1xx_hal_tim.c:5,033 0x1000a9e8	
			HAL_TIM_IRQHandler() at stm32mp1xx_hal_tim.c:3,267 0x1000a4d6	
			TIM6_IRQHandler() at stm32mp1xx_hal_timebase_tim_template.c:146 0x1000b3fe	
			<signal handler called>() at 0xffffffe9	
			__NVIC_EnableIRQ() at core_cm4.h:1,694 0x10003da2	
			HAL_NVIC_EnableIRQ() at stm32mp1xx_hal_cortex.c:188 0x10003ecc	
			HAL_InitTick() at stm32mp1xx_hal_timebase_tim_template.c:65 0x1000b360	
			HAL_Init() at stm32mp1xx_hal.c:164 0x10003c72	
			main() at main.c:137 0x10000250	
			Reset_Handler() at startup_stm32mp157caax.s:98 0x1000b4ae	
	/opt/st/stm32cubeide_1.2.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.linux64_1.0.0.201904181610/tools/bin/arm-none-eabi-gdb (8.1.0.20180315)	
	ST-LINK (ST-LINK GDB server)	

Olivier GALLIEN
ST Employee

Hi @karlchansen​ 

1 - Yes you should start from F4 example project and change SPI and TIM devices used to match what is available on MP1.

Don't you succeed to find the correct mapping referring to https://www.st.com/content/ccc/resource/technical/document/user_manual/group1/d6/59/df/e0/8f/e7/45/8f/DM00591354/files/DM00591354.pdf/jcr:content/translations/en.DM00591354.pdf

and IHM03 UM

https://my.st.com/content/ccc/resource/technical/document/user_manual/group0/57/5a/60/c7/ff/a3/4d/21/DM00206777/files/DM00206777.pdf/jcr:content/translations/en.DM00206777.pdf

?

2- yes SW4STM32 has some known limitations and is now deprecated. Let use STM32CubeIDE.

3

3.1 : I'm not sure "ST-Link GDB Server" is supported with MP1. Come back to you ASAP with clear statement

3.2 : In production mode debugger is performing an attachement on running target. So none breakpoint can be taken into account before this attachment.

What you observe in while loop is normal. This is actually one trick to deal with this situation and to be able to debug initialization steps.

3.3 No idea of what may happen. Did you properly terminate and then restart the debug session ?

If you don't mind to share your project I would be happy to help you fixing the remaining points. ( you can use private message)

Hope it help,

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
karlchansen
Associate II

Thanks! I will check internally on sharing the project, but because it is derived from an st.com example I do not believe there will be any problems.

karlchansen
Associate II

Rather than upload, just grab SPN3 V1.6.0 package:

https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-spn3.html

We have tried the examples for 1, 2, and 3 motors:

...en.x-cube-spn3.zip:

  1. STM32CubeExpansion_SPN3_V1.6.0\Projects\Multi\Examples\MotionControl\IHM03A1_ExampleFor1Motors\
  2. STM32CubeExpansion_SPN3_V1.6.0\Projects\Multi\Examples\MotionControl\IHM03A1_ExampleFor2Motors\
  3. STM32CubeExpansion_SPN3_V1.6.0\Projects\Multi\Examples\MotionControl\IHM03A1_ExampleFor3Motors\

We believe the SPIx should be set to SPI4, and we are able to see SPI traffic using a logic analyzer, but suspect we do not have timer/interrupt pins configured properly.

karlchansen
Associate II

We have also tried modifying the MP1 spi example: SPI_FullDuplex_ComIT_Master_CM4, that is part of the MP1 package for the M4, but that approach also did not work. The example works fine by itself, but as we begin to import motor-control code from SPN3, things quickly break.

chaaalyy
Senior II

Hi,

2 years ago i had to develop a controller with a IHM03A1 plugged onto a f746 discovery board. Beside many Bugs and Problems (even today still in SPN3 V1.6.0... For example: Just check the "ifdef C++", the closing brackets and "endif"at the end of the file are missing and so on...) i managed to get it to work. You need to take a closer Look to the schematic, especially for SPI (MISO, MOSI, CLK, CS) and the "Flag" Line. In my case i didn´t need to use the "Busy" line and also i didn´t use the external steps. I drove the motor directly with the SPI commands provided by the library. Most important is to get the driver initialized correctly.

So if you are able to communicate with the driver via SPI and you set up the Interrupt-routines (Flag) correctly, you should be able to get it up and running on every board with Arduino connectors 🙂

btw: In the examples, SPI setup is NOT performed in main.c… It´s somewhere hidden in the … let´s say "sometimes strangely organized code", as far, as i remember …

A couple of months ago, i tried to play around with f746, CubeMX , touchGFX in CubeIDE and three daisy-chained ihm03a1 and also got it to work. I´m just not sure, if i still have the code somewhere… It was just a quick and dirty try. As far, as i remember, i did the pin setup completely with cubeMX and disabled the mx_spi2_init in main.c later on. Then i changed the spi-settings in the example code (and the extI Line of course) to fit my discovery board and everything worked fine.

karlchansen
Associate II

..."sometimes strangely organized code...." Submitted for understatement-of-the-year award!

Such as, from the MP1 examples for M4 (SPI_FullDuplex_ComIT_Master_CM4 example to be more specific):

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
  /* USER CODE END WHILE */
    BSP_LED_Toggle(LED7);
    HAL_Delay(500);
 
  /* USER CODE BEGIN 3 */
 
  }
  /* USER CODE END 3 */

...I'm not sure I would have realized "while (1)" was an infinite loop without the comment, and can anyone explain _why_ the prefix-suffix comments are needed around the "while (1)" and around the end-brace for the loop???

Anyway, I had found the SPI setup and the defs for the SPN3 lib and had modified what I thought was appropriate. Ended up getting continuous SPI traffic that was 100% errors. The code was continuously looping on the first SPI transmission in the SPN3 init-IHM03 code and was not waiting between transmit blocks.

I'm currently looking at working from the SPI_FullDuplex example (which works just fine), and seeing if I can call the lower-level SPN3 commands.

Following that, if it does not work, I will try using the functional SPI code from this example to send the commands as raw byte sequences.

I created a map spreadsheet from the Arduino Uno V3 pins to the F4 pins (used in one of the SPN3 examples) and then to the MP1 pins. It helped us get to the "all errors" state, but not much further. One of the issues I have run into is the failure to have _all_ potential pin uses called out on the ST devices. Makes a map like the spreadsheet difficult when I find a pin referenced in the code whose name does not appear on the MP1 arduino-connector pinout.

I have used the CubeMX configurator on another project, so I may try that approach.

Thanks for the feedback!