STM32Cube FW_F7. Possible Bug introduced in V1.3.1 for SAI.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2016-01-07 01:26 AM
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- Labels:
-
SAI
-
STM32CubeMX
-
STM32F7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2016-01-08 03:03 AM
Hi
paul-h
,
Thank you for your feedback. The issue has been reported internally. - Hannibal -- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2016-01-12 09:29 AM
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-- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2016-05-11 06:42 AM
CubeMX 4.14.0 FW_F7 V1.3.1
CubeMx still generates wrong Initialvalue for parameterSlotActive,
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-01-23 07:13 AM
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.