STM32L4R5ZI-NUCLEO144 and SDC Driver: hal_sdc.h:136:10: fatal error: hal_sdc_lld.h: No such file or directory Topic is solved

[Giovanni]

Not enough info, the FS is mounted in the provided demo. Any difference could be the cause of the problem, GPIO settings, clocks, type of card and possibly others.

Giovanni

[sntnjrg]

Hi Giovanni,

I'm sorry, I had a broken wire. I tried again and it failed when the f_write() function is invoked to write a data. The error occurs after validating the file object. The error is FR_DISK_ERR.

Code: Select all

FRESULT f_write (
   FIL* fp,         /* Pointer to the file object */
   const void* buff,   /* Pointer to the data to be written */
   UINT btw,         /* Number of bytes to write */
   UINT* bw         /* Pointer to number of bytes written */
)
{
   FRESULT res;
   FATFS *fs;
   DWORD clst, sect;
   UINT wcnt, cc, csect;
   const BYTE *wbuff = (const BYTE*)buff;


   *bw = 0;   /* Clear write byte counter */
   res = validate(&fp->obj, &fs);         /* Check validity of the file object */
   if (res != FR_OK || (res = (FRESULT)fp->err) != FR_OK) LEAVE_FF(fs, res); <--- HERE,


The test tries to write a data 10000 times but fails 9984 times.

Code: Select all

  uint32_t write_errors = 0;
  for (uint32_t i = 0; i < 10000; i++) {
    err = f_write(&FileObject, teststring, sizeof(teststring),
                  (void*)&bytes_written);
    if (err != FR_OK) {
      write_errors++;
    }
  }


After this part, the f_close() function is invoked. This function invokes f_sync() and then disk_write(). The function disk_write() invokes the sdcWrite() function and .... The stack is:

Code: Select all

Thread #1 (Suspended : Step)   
   sdc_lld_wait_transaction_end() at hal_sdc_lld.c:225 0x8002e08   
   sdc_lld_write_aligned() at hal_sdc_lld.c:749 0x80034a6   
   sdc_lld_write() at hal_sdc_lld.c:826 0x80035d2   
   sdcWrite() at hal_sdc.c:846 0x8001f84   
   disk_write() at fatfs_diskio.c:188 0x800a7a0   
   f_sync() at ff.c:3.971 0x800cbba   
   f_close() at ff.c:4.045 0x800cc8c   
   fs_test() at main.c:564 0x801609c   
   cmd_sdiotest() at main.c:669 0x801636e   
   cmdexec() at shell.c:106 0x8009f0c   
   <...more frames...>   


Code: Select all

/**
 * @brief   Wait end of data transaction and performs finalizations.
 *
 * @param[in] sdcp      pointer to the @p SDCDriver object
 * @param[in] n         number of blocks in transaction
 * @param[in] resp      pointer to the response buffer
 *
 * @return              The operation status.
 * @retval HAL_SUCCESS  operation succeeded.
 * @retval HAL_FAILED   operation failed.
 */
static bool sdc_lld_wait_transaction_end(SDCDriver *sdcp, uint32_t n,
                                         uint32_t *resp) {

  /* Note the mask is checked before going to sleep because the interrupt
     may have occurred before reaching the critical zone.*/
  osalSysLock();
  if (sdcp->sdmmc->MASK != 0)
    osalThreadSuspendS(&sdcp->thread); <-- HERE

  /* Stopping operations.*/
  sdcp->sdmmc->IDMACTRL = 0;
  sdcp->sdmmc->MASK     = 0;
  sdcp->sdmmc->DCTRL    = 0;

  if ((sdcp->sdmmc->STA & SDMMC_STA_DATAEND) == 0) {
    osalSysUnlock();
    return HAL_FAILED;
  }

  /* Clearing status.*/
  sdcp->sdmmc->ICR      = SDMMC_ICR_ALL_FLAGS;
  osalSysUnlock();

  /* Finalize transaction.*/
  if (n > 1)
    return sdc_lld_send_cmd_short_crc(sdcp, MMCSD_CMD_STOP_TRANSMISSION, 0, resp);

  return HAL_SUCCESS;
}


The sdcp->sdmmc->MASK field is not equal to 0 and the thread is sent to sleep and never wakes up.

The configuration (clock, ...) that I am using is the one that by default comes in the RT-STM32L4R5ZI-NUCLEO144 demo on master branch.

Does the demo work for you in the current master branch of Chibios?

Thank you

[Giovanni]

What is the value of MASK when it fails?

Giovanni

[sntnjrg]

Hi Giovanni,

This is its value: 282.

and this is the state at this moment:

Code: Select all

sdcp   SDCDriver *   0x20000d58 <SDCD1>   
   vmt   const struct SDCDriverVMT *   0x8016c4c <sdc_vmt>   
   state   blkstate_t   BLK_WRITING   
   cid   uint32_t [4]   0x20000d60 <SDCD1+8>   
   csd   uint32_t [4]   0x20000d70 <SDCD1+24>   
   capacity   uint32_t   15138816   
   config   const SDCConfig *   0x8016d5c <sdc_default_cfg>   
   cardmode   sdcmode_t   17   
   errors   sdcflags_t   4   
   rca   uint32_t   4219667744   
   thread   thread_reference_t   0x0   
   sdmmc   SDMMC_TypeDef *   0x50062400   
      POWER   volatile uint32_t   3   
      CLKCR   volatile uint32_t   20480   
      ARG   volatile uint32_t   1562264   
      CMD   volatile uint32_t   344   
      RESPCMD   const volatile uint32_t   24   
      RESP1   const volatile uint32_t   2304   
      RESP2   const volatile uint32_t   0   
      RESP3   const volatile uint32_t   0   
      RESP4   const volatile uint32_t   0   
      DTIMER   volatile uint32_t   1000000   
      DLEN   volatile uint32_t   512   
      DCTRL   volatile uint32_t   144   
      DCOUNT   const volatile uint32_t   512   
      STA   const volatile uint32_t   69632   
      ICR   volatile uint32_t   0   
      MASK   volatile uint32_t   282   
      ACKTIME   volatile uint32_t   0   
      RESERVED0   uint32_t [3]   0x50062444   
      IDMACTRL   volatile uint32_t   1   
      IDMABSIZE   volatile uint32_t   0   
      IDMABASE0   volatile uint32_t   537525452   
      IDMABASE1   volatile uint32_t   0   
      RESERVED1   uint32_t [8]   0x50062460   
      FIFO   volatile uint32_t   0   
   clkfreq   uint32_t   48000000   
   buf   uint8_t [512]   0x20000da0 <SDCD1+72>   
n   uint32_t   1   
resp   uint32_t *   0x2009f42c   


Thanks for the help

[Giovanni]

Hi,

282 (0x11A) means that the problem occurred on a write but it could have occurred on a read because the code is very similar.

Could you check your IRQ priority for SDMMC into NVIC? that problem makes no sense, I suspect there is something wrong with that (IRQ preempting the critical zone and make that check fail). Priorities 0 and 1 can preempt the kernel, 2 is reserved so 3..15 should be used.

Giovanni

[sntnjrg]

Hi Giovanni,

I'm sorry, I'm a bit puzzled and I don't know if I'm answering your question (I'm newbie).

In mcuconf.h file, the value is:

Code: Select all

#define STM32_IRQ_SDMMC1_PRIORITY           9


In chibios_stable-20.3.x/os/hal/ports/STM32/STM32L4xx+/platform.mk file, you can be found the following definition:

Code: Select all

include $(CHIBIOS)/os/hal/ports/STM32/LLD/SDMMCv2/driver.mk


In chibios_stable-20.3.x/os/hal/ports/STM32/LLD/SDMMCv2/stm32_sdmmc1.inc file, the following is found:

Code: Select all

static inline void sdmmc1_irq_init(void) {
#if STM32_SDMMC1_IS_USED
  nvicEnableVector(STM32_SDMMC1_NUMBER, STM32_IRQ_SDMMC1_PRIORITY);
#endif
}

static inline void sdmmc1_irq_deinit(void) {
#if STM32_SDMMC1_IS_USED
  nvicDisableVector(STM32_SDMMC1_NUMBER);
#endif
}


In chibios_stable-20.3.x/os/hal/ports/STM32/LLD/SDMMCv2/stm32_sdmmc2.inc file, the following is found:

Code: Select all

static inline void sdmmc2_irq_init(void) {
#if STM32_SDMMC2_IS_USED
  nvicEnableVector(STM32_SDMMC2_NUMBER, STM32_IRQ_SDMMC2_PRIORITY);
#endif
}

static inline void sdmmc2_irq_deinit(void) {
#if STM32_SDMMC2_IS_USED
  nvicDisableVector(STM32_SDMMC2_NUMBER);
#endif
}


Thanks for the help.

[Giovanni]

Try putting -DCORTEX_SIMPLIFIED_PRIORITY=1 in your makefile (UDEFS and UADEFS) and see if it helps with your problem.

Giovanni

[sntnjrg]

Hi Giovanni,

The same problem still exists: MASK volatile uint32_t 282

Code: Select all

sdcp   SDCDriver *   0x20000dd8 <SDCD1>   
   vmt   const struct SDCDriverVMT *   0x8016ebc <sdc_vmt>   
   state   blkstate_t   BLK_WRITING   
   cid   uint32_t [4]   0x20000de0 <SDCD1+8>   
   csd   uint32_t [4]   0x20000df0 <SDCD1+24>   
   capacity   uint32_t   15138816   
   config   const SDCConfig *   0x8016fe4 <sdc_default_cfg>   
   cardmode   sdcmode_t   17   
   errors   sdcflags_t   4   
   rca   uint32_t   4219667744   
   thread   thread_reference_t   0x0   
   sdmmc   SDMMC_TypeDef *   0x50062400   
      POWER   volatile uint32_t   3   
      CLKCR   volatile uint32_t   20480   
      ARG   volatile uint32_t   1562270   
      CMD   volatile uint32_t   344   
      RESPCMD   const volatile uint32_t   24   
      RESP1   const volatile uint32_t   2304   
      RESP2   const volatile uint32_t   0   
      RESP3   const volatile uint32_t   0   
      RESP4   const volatile uint32_t   0   
      DTIMER   volatile uint32_t   1000000   
      DLEN   volatile uint32_t   512   
      DCTRL   volatile uint32_t   144   
      DCOUNT   const volatile uint32_t   512   
      STA   const volatile uint32_t   69632   
      ICR   volatile uint32_t   0   
      MASK   volatile uint32_t   282   
      ACKTIME   volatile uint32_t   0   
      RESERVED0   uint32_t [3]   0x50062444   
      IDMACTRL   volatile uint32_t   1   
      IDMABSIZE   volatile uint32_t   0   
      IDMABASE0   volatile uint32_t   537525452   
      IDMABASE1   volatile uint32_t   0   
      RESERVED1   uint32_t [8]   0x50062460   
      FIFO   volatile uint32_t   0   
   clkfreq   uint32_t   48000000   
   buf   uint8_t [512]   0x20000e20 <SDCD1+72>   
n   uint32_t   1   
resp   uint32_t *   0x2009f42c


I attach some photos of the reader and the wiring.

Could it be a reader hardware problem?

Another strange thing is that when I make a tree it doesn't always work and it doesn't list all the files.

Code: Select all

ChibiOS/RT Shell
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
/SYSTEM~1/INDEXE~1
/SYSTEM~1/WPSETT~1.DAT
/080720~2.TXT
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
/SYSTEM~1/INDEXE~1
/SYSTEM~1/WPSETT~1.DAT
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
/SYSTEM~1/INDEXE~1
/SYSTEM~1/WPSETT~1.DAT
/080720~2.TXT
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
/SYSTEM~1/INDEXE~1
/SYSTEM~1/WPSETT~1.DAT
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
/SYSTEM~1/INDEXE~1
/SYSTEM~1/WPSETT~1.DAT
/080720~2.TXT
ch> tree
FS: 233482 free clusters with 64 sectors (32768 bytes) per cluster
/SYSTEM~1/INDEXE~1
/SYSTEM~1/WPSETT~1.DAT
ch>


Thanks you

[sntnjrg]

Hi Giovanni,

In order for you to better observe the problem, I have adapted this example for the STM32L4R5ZI-NUCLEO144 board model:

Code: Select all

https://github.com/ChibiOS/ChibiOS/tree/master/testhal/STM32/STM32F4xx/SDC


I'm newbie and my code may be wrong. With this adaptation, I minimize the error and you can see the problem. I'm attaching the adaptation.

When you run the following command:

Code: Select all

ChibiOS/RT Shell
ch> sdc all
Connecting... OK

Card Info
CSD      : 400E0032 5B590000 39BF7F80 0A4000AC
CID      : 02544D53 45303847 22C02CFA A100F1DC
Mode     : SDV20
Capacity : 7392MB
Single block aligned read performance:           681 blocks/S, 348672 bytes/S
16 sequential blocks aligned read performance:   9840 blocks/S, 5038080 bytes/S
Single block unaligned read performance:         906 blocks/S, 463872 bytes/S
16 sequential blocks unaligned read performance: 672 blocks/S, 344064 bytes/S
Writing...OK
Reading...OK
Writing...OK
Reading...OK



sdcp->sdmmc->MASK has a value has a value different than 0. When I pause the execution, I notice the following in the stack:

Code: Select all

SDC-RT-STM32L4R5ZI-NUCLEO144 (OpenOCD, Flash and Run) [GDB Hardware Debugging]   
   ch.elf   
      Thread #1 (Suspended : Signal : SIGINT:Interrupt)   
         _idle_thread() at chcore_v7m.h:774 0x8009be0   
         _port_thread_start() at chcoreasm_v7m.S:210 0x80002ba   
   arm-none-eabi-gdb (8.3.0.20190703)   



In the editor, the cursor stays on the next line:

Code: Select all

/**
 * @brief   Enters an architecture-dependent IRQ-waiting mode.
 * @details The function is meant to return when an interrupt becomes pending.
 *          The simplest implementation is an empty function or macro but this
 *          would not take advantage of architecture-specific power saving
 *          modes.
 * @note    Implemented as an inlined @p WFI instruction.
 */
__STATIC_FORCEINLINE void port_wait_for_interrupt(void) {

#if CORTEX_ENABLE_WFI_IDLE == TRUE
  __WFI();
#endif
} // <-- Cursor here


Thanks for the help.

[Giovanni]

Hi,

How many times do you need to run that command to see the problem? I am trying on an STM32L4R9AI-Discovery and it never happens.

I added a demo here: /chibios_trunk/testhal/STM32/multi/SDMMC

It is normal to find the cursor in port_wait_for_interrupt(), it is within the idle thread loop. It means all other threads are sleeping.

Edit: it was an STM32L4R9 but it makes no difference.

Giovanni