STM32F4 Discovery MB997B and MB997C differences

[richard239955_stm1]

Posted on October 11, 2017 at 02:30

I am working on a problem with DSP Concepts. I have an STM32F4 Discovery MB997B and they have an STM32F407 Discovery MB997C-01.

They have modified their code that runs on the STM32F4 Discovery module and provided that code to me, compiled with EWARM, MDK_ARM and SW4STM32, three seperate mailings of each of the binaries, nine in total.

Below is a summary of my observations with my module, and they have matched the version of ST-Link Utility (the latest) that I am using. I am not using any USB hubs and have followed their instructions completely and am finding differences in each release and in each different compiler and they are reporting that their MB997C-01 works with every release and every different compiled version

The unknown differences between theri setup and my setup is my computer, and STM32F4 Discovery module. We have eliminated all other software differences.

So, the question is, whta are the exact differences between my MB997B and their MB997C?

Tossing one out off the top of my head here, is it possible the silicon in my chip (STM32F407VGT6) is different than theirs, such that the DSP instructions have a couple of bugs on my MB997B module that are not in their MB997C-01 module?

Together, myself and DSP Concepts, have been working this problem for a number of days and I am reaching out to folks here who could/should be in the know as to what the hardware differences are that are confounding our success in arriving at a solution.

---------------------------------------------------------------------------

00-AWE BSP stm32f746 v1.2

- STM32F746_Discovery.bin - never ran

01-awe-bsp-stm32f407-discovery_10-7-2017.rar

- STM32F407_Discovery_EWARM.bin -runs for more than 10 minutes- STM32F407_Discovery_MDK_ARM.bin - runs for more than 10 minutes- STM32F407_Discovery_SW4STM32.bin - crashed after short time

02-awe-bsp-stm32f407-discovery.zip

- STM32F407_Discovery_EWARM.bin - crashed- STM32F407_Discovery_MDK_ARM.bin - runs for more than 10 minutes- STM32F407_Discovery_SW4STM32.bin - does not run produces a USB device error

03-awe-bsp-stm32f407-discovery_ST_version_10-7-2017.zip

- STM32F407_Discovery_EWARM.bin - crashed- STM32F407_Discovery_MDK_ARM.bin runs for more than 10 minutes- STM32F407_Discovery_SW4STM32.bin - does not run produces a USB device error#stm32f$-discovery-mb997b-versus-mb997c

[Tesla DeLorean]

Posted on October 11, 2017 at 02:45

More probably clocks, PLL and FLASH settings, I've got code in system_stm32f4xx.c that auto-detects 401C, 411 and 407 parts on assorted STM32F4-DISCO/DISC1/MB997 boards without issue and clocks each optimally.

Check the cores

https://community.st.com/0D50X00009XkYbhSAF

And decode RCC settings

Have a functional Hard Fault Handler so you learn something if it crashes into that

https://community.st.com/0D50X00009XkfOXSAZ

Any code dependencies on the CODEC or motion sensor?

'The LIS302DL is present on board MB997B (PCB revision B) and the LIS3DSH is present on board MB997C (PCB rev C).'

>>

Together, myself and DSP Concepts, have been working this problem for a number of days and I am reaching out to folks here who could/should be in the know as to what the hardware differences are that are confounding our success in arriving at a solution.

Open to reasonable offers for my time.

[Jan Waclawek]

Posted on October 11, 2017 at 07:28

Different ratio between PC's and mcu's (I2S) clock may lead to buffers under/overflow, one of them may be handled incorrectly.

JW

[AvaTar]

Posted on October 11, 2017 at 08:20

- STM32F407_Discovery_EWARM.bin -runs for more than 10 minutes

- STM32F407_Discovery_MDK_ARM.bin - runs for more than 10 minutes- STM32F407_Discovery_SW4STM32.bin - crashed after short time

Different compilers build different executables, and 10 minutes are quite along time.

I would suspect a race condition, most probably with interrupt handlers.

'DSP' sounds like high core load in tight interrupt loops.

[richard239955_stm1]

Posted on October 12, 2017 at 17:49

All things considered, I am instructing DSP Concepts to not work on this problem any further. There appear to be a number of issues with the Revision A chip on my STM32F4 Discovery MB997B module, many of which could well be the cause of the problems I am seeing.

I will get newer module and that will resolve the problem and suggest to DSP Concepts that they state that the application is restricted to Revision C or greater modules.

Thank you everyone for your valuable input.

[Tesla DeLorean]

Posted on October 12, 2017 at 17:12

Older 407 parts have a flaw in the prefetch, this must be disabled, but doubt these would be on C or D boards, or frankly B's

[Tesla DeLorean]

Posted on October 12, 2017 at 17:15

I'd watch the heap if malloc/free are used repetitively. The stack could be an issue if combination of events over time exposes worst-case usage patterns.

The stack in KEIL/IAR is tight with the statics, with GNU is typically placed at top of memory so less likely to collide with heap/statics/locale data. Keil defaults to stupidly small stack based on setting in startup_stm32f4xx.s

[Tesla DeLorean]

Posted on October 12, 2017 at 18:00

The RevA just doesn't want the prefetch enabled, but it's not remotely hard to identify

devid = DBGMCU->IDCODE & 0xFFF;

...

if (devid != 0x411) // 0x20006411 RevA 407 Prefetch broken

  ws |= FLASH_ACR_PRFTEN;

..

/* Configure Flash prefetch, Instruction cache, Data cache and wait state */

FLASH->ACR = FLASH_ACR_ICEN | FLASH_ACR_DCEN | ws;