2018-11-10 03:06 AM
Hi, i have a problem with my project....I'm using Fat and SD with freertos to read/write files on SD using hdma channel.
First part i fixed all "SDIO_STA_STBITER" with "SDIO_STA_STBITERR" (with 2 "R" ) because a typo is present.
But i see the interrupt HAL_SD_IRQHandler starting without reason .
For example,
if( f_open( &MyFile, MyFileName, FA_READ ) == FR_OK )
{
/* Get file status */
FileOut.size = MyFileInfo.fsize;
f_close( &MyFile );
}
else
{
// tiro una bestemmia
}
while ( 1 ) osDelay ( 100 );
Here the operation on SD must be completed.... instead, if you put now a brakpoint on HAL_SD_IRQHandler , you will see in random time (can be immediatly or after also 5/6 minutes) a interrupt request generated by SDIO_IT_DTIMEOUT.
This interrupt will call a HAL_DMA_Abort_IT() and all the next operations of writing will fail because the pointer to hdmtx its void
Have you forgot some parts ?
Its normal to keep SD interrupts active also after the end of operations ?
And also inside HAL_SD_IRQHandler ....
/* Abort the SD DMA Streams */
if(hsd->hdmatx != NULL)
{
/* Set the DMA Tx abort callback */
hsd->hdmatx->XferAbortCallback = SD_DMATxAbort;
/* Abort DMA in IT mode */
if(HAL_DMA_Abort_IT(hsd->hdmatx) != HAL_OK)
{
SD_DMATxAbort(hsd->hdmatx);
}
}
else if(hsd->hdmarx != NULL)
{
/* Set the DMA Rx abort callback */
hsd->hdmarx->XferAbortCallback = SD_DMARxAbort;
/* Abort DMA in IT mode */
if(HAL_DMA_Abort_IT(hsd->hdmarx) != HAL_OK)
{
SD_DMARxAbort(hsd->hdmarx);
}
}
else
{
hsd->ErrorCode = HAL_SD_ERROR_NONE;
hsd->State = HAL_SD_STATE_READY;
HAL_SD_AbortCallback(hsd);
}
Comment say "/* Abort the SD DMA Streams */"... are you sure abort streams ? With "else" between, you will abort only one stream for each errror.... so first error abort "hdmatx", second error abort "hdmarx" and third error you will call "HAL_SD_AbortCallback"..
What did you want to do ?
I know, my english is worse than yours code ! =)
Bye bye
2018-11-12 06:16 AM
I had similar problems with an F7, so I hope this helps with your L4.
For the unexpected DTIMEOUT interrupt: in SD_DMAReceiveCplt() write a 0x0 to DCTRL instead of just clearing the DMAEN bit. Even though DTEN is supposed to auto-clear at the end of the transfer (stopping the Data Timeout timer) it appears that it sometimes doesn't actually stop the timer.
Also, if you stare at it long enough you'll probably see that clearing the Static Flags really isn't the right thing to do in this routine. Just clear the DPSM-related flags via SDMMC_STATIC_DPSM_FLAGS instead. I added a definition for SDMMC_STATIC_DPSM_FLAGS to the ..._ll_sdmmc.h file:
#define SDMMC_STATIC_DPSM_FLAGS ((uint32_t)(SDMMC_FLAG_DCRCFAIL | \
SDMMC_FLAG_DTIMEOUT | SDMMC_FLAG_TXUNDERR | SDMMC_FLAG_RXOVERR | \ SDMMC_FLAG_DATAEND | SDMMC_FLAG_DBCKEND))
(Sorry for the formatting - this forum ***** in many ways.)
Regarding the DMA stream aborts: yeah, it's a mess without any good explanation..
2018-11-12 07:21 AM
Thank you i will check immediatly !
2018-11-12 08:40 AM
Also on this first generation F4 parts, DO NOT use FLOW CONTROL, disable it in the HAL_SD_Init() request.
2018-11-12 09:24 AM
Shouldn't this problem be described in the Errata (or did I miss it)?
2018-11-12 09:34 AM
Already disabled... :(
2018-11-12 10:42 AM
I don't know, it works in F412 parts, doesn't work properly in F439/F427 type parts. Not paid enough by ST to waste more time on it root causing the silicon or software side.
Errata mentioned here, but can testify to wasting a few hours when I was back-porting some eMMC demo code across some F4 platforms, and HAL examples for those platforms.
2018-11-12 10:48 AM
Sorry, i solved.... :( my fault.
Wrong priority on DMA IRQ
2018-11-12 10:50 AM
More specifically I don't think the example mentions it, just glosses over it with subtly different HAL_SD_Init() settings on each platform.
One of those conveniently pre-dug holes for people to fall into. See also pit-traps
2018-11-12 11:26 AM
Sorry, I solved, my fault !! Wrong priority in DMA IRQ