• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 301 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

MSP432E401Y: EPI and USB

MSP432E401Y: A particular pendrive crashes TI USBlib in USBMSCH_hwiHandler()

Peter Toth
Prodigy 220 points
Part Number: MSP432E401Y
Other Parts Discussed in Thread: SYSBIOS

Hi,

On a custom board with MSP432E401Y, I'm working on bringing up the USB port. I've ported most of the code from usb_msc_host example code. It works correctly for most of my pendrives. I can list, cat, do anything.

Except one pendrive, which causes a crash every single time I connect it to the board. I'm using LoggerStopMode and TI-RTOS/SysBIOS to determine the source of the crash. Using CCS10 with XDC 3.61.0.16, MSP432E SDK 4.10.0.13, CCS compiler v20.2.1LTS.

What I know:

- the PC is always 0 for this crash: "{module#42}: line 978: error {id:0x120000, args:[0x3, 0x0]}", aka I can't get an exception stack in ROV->Hwi->Exception->Exception Call Stack. Only the function that is at 0x0 address is shown.

- USBMSCH_hwiHandler is the last thing running in Live View 

- I can reproduce this every single time with the pendrive.

- Pendrive works perfectly (can R/W at will) with my Win10 Intel desktop.

- Pendrive formatted to FAT32

- The issue doesn't happen if I'm trying to iterate through 100 breakpoints in the USB interrupt handler.

- The pendrive is an average no-name 1GB pendrive, using Hynix flash chips and a controller, on which I can't quite read the markings.

- I've tried the usb_msc_host code on the MSP432E401Y launchpad, using this pendrive, and I've had success reading it.

- The pendrive is flashing on boot up, thus some activity must be happening. (On power only it will just show red.)

- I've increase task/IRQ stack sizes to make sure it is not getting corrupt.

Any ideas what could I do next. I can toggle and measure GPIO pins in interrupts, I'm considering implementing my own structure to track where the interrupt is going to look at memory browser post mortem.

Thanks,

Peter

  • 0
    TI__Genius 12615 points

    Hi Peter,

    I'm consulting with a colleague on this and will get back to you.

    BR,
    Leo

  • 0 in reply to Leonardo Estevez
    Prodigy 220 points

    Thanks Leo. Let me know.

  • 0 in reply to Peter Toth
    Prodigy 220 points

    Hi Leo,

    It is a bit inconsistent with my yesterday's crash (since yesterday the crash seemed to be after executing the IRQ), but this morning I've caught a crash on the call of:

    usbhostenum.c:USBHostIntHandlerInternal -> ui32DMAIntStatus = USBLibDMAIntStatus(g_sUSBHCD.psDMAInstance);

    g_sUSBHCD.psDMAInstance->pfnIntStatus is NULL 

    I did avoid calling the function, which resulted in working scenario for all good pendrives, but the problematic pendrive is still not working (at least not crashing). Also after the problematic pendrive no other pendrives work. I presume this is because there is still an unhandled interrupt waiting, as confirmed by ROV->HWI.

    Also if I change the call from USBLibDMAIntStatus to iDMAUSBIntStatus, which is the function called in the end the problematic pendrive crashes the code now at:

    I'm now trying to track down when these function pointers get corrupted, but any help and pointers are still welcome, since the issue still not resolved. 

    Cheers,

    Peter

  • 0 in reply to Peter Toth
    Prodigy 220 points

    Hi Leo,

    I've found the bug. The peculiarity of the pendrive is that its sector size is 4096bytes (physical), all the others I have are 512bytes (including Kingstons and Sandisks).

    The FatFS library in the SDK is configured with 512byte sector size. ffconf.h:512 #define MAX_FF_SS 512 thus a 512 byte buffer is going to be allocated in static FATFS fatFs; If you refer back to the call stack I've posted in the above comment there is no size transfer between stack #6 & #5. Aka #5 makes up the sector size. Conveniently takes the sector size read from the pendrive, which in this case is 4096. And passes the 512 byte buffer pointer with a 4096 size. Buffer overrun corrupts many buffers, especially g_psUSBDMAInst, which will end up with NULLs for its function pointers, hence the crash.

    To correct it I expect to make two changes:

    1. Bring FatFS into the my project, so I can change MAX_FF_SS to 4096. Is there any way of doing this otherwise?

    2. Add a sanity check into FATUSBMSC_diskRead for sector size. The check would ideally be in USBHMSCBlockRead in usbhmsc.c in the usblib.

    Hope this makes sense. Anything else I'm forgetting?

    Cheers,

    Peter

    Further bugs in the library:

    1. In USBHCDLPMSleep (there are few more of these around the file)

    //
    // Disable the USB interrupt.
    //
    OS_INT_ENABLE(g_sUSBHCD.ui32IntNum);

    2. There is a call to USBHostEndpointStatusClear in USBHostIntHandlerInternal which should be MAP_USBHostEndpointStatusClear . Will save a few bytes of flash.

**Attention** This is a public forum