Skip to main content
Howcroft.Paul
Howcroft.Paul
Associate
January 7, 2016
Question

STM32Cube FW_F7. Possible Bug introduced in V1.3.1 for SAI.

  • January 7, 2016
  • 4 replies
  • 862 views
Posted on January 07, 2016 at 10:26

Possible bug Introduced in STM32Cube FW_F7 V1.3.1 for the Serial Audio Interface.

I am developing an application for the STM32F745VG using STM32CubeMX.

This uses a SAI operating in Transmit mode, with ''Free'' protocol, and 16 Slots active.

The code functioned correctly when generated with version 1.2.0 of STM32CubeF7.

The code didn't function correctly after I upgraded to version 1.3.1 of STM32CubeF7

(no SAI data was present and no DMA complete interrupts were being generated).

Comparison of the code generated for 1.2.0 and 1.3.1 shows a problem in the initialization of the SLOTR register within stm32f7xx_hal_sai.c : HAL_SAI_Init().

With 16 slots enabled, the value contained with hsai->SlotInit.SlotActive = 0xFFFF0000.

In the 1.2.0 version of the function, SLOTR is initialized as;

hsai->Instance->SLOTR|=  

    hsai->SlotInit.FirstBitOffset |  hsai->SlotInit.SlotSize

    | (hsai->SlotInit.SlotActive ) | ((hsai->SlotInit.SlotNumber - 1) <<  8);

In the 1.3.1 version of the function, SLOTR is initialized as;

hsai->Instance->SLOTR|=  

    hsai->SlotInit.FirstBitOffset |  hsai->SlotInit.SlotSize

    | (hsai->SlotInit.SlotActive

<<16

) | ((hsai->SlotInit.SlotNumber - 1) <<  8);

The latter results in zero being set in the SLOTEN bits.

I have patched the 1.3.1 function to remove the ''<< 16'' and this appears to fix the problem.

#cubemx #stm32f7 #sai
This topic has been closed for replies.

4 replies

Walid FTITI_O
Walid FTITI_O
Visitor II
January 8, 2016
Posted on January 08, 2016 at 12:03

Hi

paul-h

,

Thank you for your feedback. The issue has been reported internally.

- Hannibal -
Walid FTITI_O
Walid FTITI_O
Visitor II
January 12, 2016
Posted on January 12, 2016 at 18:29

Hi paul-h,

I have checked internally and everything is OK with the 1.3.1 version. The problem is coming from your project.

You have to check your code generation with STM32CubeMx after upgrade :

You should ensure that both SAI driver (.C) and header(.h) files are in the same version. ( maybe problem coming from wrong “SAI_Block_Slot_Active� define in your project due to old header file version.)

-Hannibal-
thomfischer
thomfischer
Senior
May 11, 2016
Posted on May 11, 2016 at 15:42

CubeMX 4.14.0 FW_F7 V1.3.1

CubeMx still generates wrong Initialvalue for parameter

SlotActive,

I use ''User Setting'' for SlotActive

and it shows wrong ''Slot Active Final Value''

e.g.

// hsai_BlockA1.SlotInit.SlotActive = 0x000F0000; //

wron CubeMX inital value

hsai_BlockA1.

SlotInit

.

SlotActive

= 0x0000000F; // corrected

the shift is done in HAL_SAI_Init

() as paul-h mentioned.

to patch function

HAL_SAI_Init

() is not the correct way, because it is used by other

functions like

HAL_SAI_InitProtocol(),

which use #defines from stm32f7xx_hal_sai.h

#define

SAI_SLOT_NOTACTIVE ((uint32_t)0x00000000)

#define

SAI_SLOTACTIVE_0 ((uint32_t)0x00000001)

...

#define

SAI_SLOTACTIVE_15 ((uint32_t)0x00008000)

#define

SAI_SLOTACTIVE_ALL ((uint32_t)0x0000FFFF)

please correct CubeMx,

best regards

Amel NASRI
Amel NASRI
Technical Moderator
January 23, 2017
Posted on January 23, 2017 at 16:13

Hi

Fischer.Thomas.004

‌,

I checked in current version of CubeMX (4.19): the issue is already fixed in the generated code.

-Amel

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.
Terms & ConditionsAccessibility statement