Bug Report on Code Generation for NUCLEO-G474RE

[CH1]

Not a big bug but I wanted to mention it as it tripped me up.

I am using STM32CubeMX 5.6.1 with IDE System Workbench 2.9.1

I have found that when I setup SPI DMA synchronization the request number doesn't change from 1 when I generate the code or save, regardless of what the value is set too.

These are my CubeMX SPI settings

SPI3.CLKPhase=SPI_PHASE_1EDGE
SPI3.CRCCalculation=SPI_CRCCALCULATION_ENABLE
SPI3.CRCLength=SPI_CRC_LENGTH_8BIT
SPI3.DataSize=SPI_DATASIZE_8BIT
SPI3.Direction=SPI_DIRECTION_2LINES
SPI3.IPParameters=VirtualType,Mode,Direction,DataSize,CLKPhase,CRCCalculation,CRCLength
SPI3.Mode=SPI_MODE_SLAVE
SPI3.VirtualType=VM_SLAVE

and these are my DMA settings

Dma.Request0=SPI3_RX
Dma.Request1=SPI3_TX
Dma.RequestsNb=2
Dma.SPI3_RX.0.Direction=DMA_PERIPH_TO_MEMORY
Dma.SPI3_RX.0.EventEnable=DISABLE
Dma.SPI3_RX.0.Instance=DMA1_Channel1
Dma.SPI3_RX.0.MemDataAlignment=DMA_MDATAALIGN_BYTE
Dma.SPI3_RX.0.MemInc=DMA_MINC_ENABLE
Dma.SPI3_RX.0.Mode=DMA_CIRCULAR
Dma.SPI3_RX.0.PeriphDataAlignment=DMA_PDATAALIGN_BYTE
Dma.SPI3_RX.0.PeriphInc=DMA_PINC_DISABLE
Dma.SPI3_RX.0.Polarity=HAL_DMAMUX_REQ_GEN_RISING
Dma.SPI3_RX.0.Priority=DMA_PRIORITY_LOW
Dma.SPI3_RX.0.RequestNumber=1
Dma.SPI3_RX.0.RequestParameters=Instance,Direction,PeriphInc,MemInc,PeriphDataAlignment,MemDataAlignment,Mode,Priority,SignalID,Polarity,RequestNumber,SyncSignalID,SyncPolarity,SyncEnable,EventEnable,SyncRequestNumber
Dma.SPI3_RX.0.SignalID=NONE
Dma.SPI3_RX.0.SyncEnable=DISABLE
Dma.SPI3_RX.0.SyncPolarity=HAL_DMAMUX_SYNC_NO_EVENT
Dma.SPI3_RX.0.SyncRequestNumber=1
Dma.SPI3_RX.0.SyncSignalID=NONE
Dma.SPI3_TX.1.Direction=DMA_MEMORY_TO_PERIPH
Dma.SPI3_TX.1.EventEnable=ENABLE
Dma.SPI3_TX.1.Instance=DMA1_Channel2
Dma.SPI3_TX.1.MemDataAlignment=DMA_MDATAALIGN_BYTE
Dma.SPI3_TX.1.MemInc=DMA_MINC_ENABLE
Dma.SPI3_TX.1.Mode=DMA_CIRCULAR
Dma.SPI3_TX.1.PeriphDataAlignment=DMA_PDATAALIGN_BYTE
Dma.SPI3_TX.1.PeriphInc=DMA_PINC_DISABLE
Dma.SPI3_TX.1.Polarity=HAL_DMAMUX_REQ_GEN_RISING
Dma.SPI3_TX.1.Priority=DMA_PRIORITY_LOW
Dma.SPI3_TX.1.RequestNumber=1
Dma.SPI3_TX.1.RequestParameters=Instance,Direction,PeriphInc,MemInc,PeriphDataAlignment,MemDataAlignment,Mode,Priority,SignalID,Polarity,RequestNumber,SyncSignalID,SyncPolarity,SyncEnable,EventEnable,SyncRequestNumber
Dma.SPI3_TX.1.SignalID=NONE
Dma.SPI3_TX.1.SyncEnable=ENABLE
Dma.SPI3_TX.1.SyncPolarity=HAL_DMAMUX_SYNC_FALLING
Dma.SPI3_TX.1.SyncRequestNumber=1
Dma.SPI3_TX.1.SyncSignalID=HAL_DMAMUX1_SYNC_EXTI1

You can see it registers the Sync Request Number as 1. If I manually change the .ioc file to another value in a text editor the value stays and gets saved and generated properly.

[Nesrine.JLASSI]

Hello @CH​ 

Could you please share your ioc file to check the issue.

Best regards,

Nesrine

[CH1]

Please find it attached.

[CH1]

Different topic but on the same setup.

I spent some time playing with the ADC yesterday just to test its features and noticed that the input clock prescaler setting doesn't force the user to use a ADC frequency lower then the maximum suggested in the datasheet. I might be misunderstanding something on this but I am pretty sure it allowed me to set the ADC clock too fast. eg I set the ADC clock source to the SYSCLK running at 120MHz. I can generate code with the prescaler setting, "Asynchronus clock mode divided by 1" resulting in a ADC clock of 120MHz, much faster then the maximum 60MHz.

I know on other ICs if the ADC clock source combined with the clock prescaler options result in a ADC clock that is too fast the prescaler options are greyed out.

[Nesrine.JLASSI]

Hello @CH​ 

Thanks for the feedback, issue detected, it will be fixed next STM32CubeMX version.

Best regards,

Nesrine