Skip to main content
glinsky
Associate
June 5, 2013
Question

STM32L EEPROM writing with USB VCP trouble

  • June 5, 2013
  • 2 replies
  • 792 views
Posted on June 05, 2013 at 07:47

Hi!

I'm using STM32L152 + IAR6.5.

EEPROM writing/erazing routings are placed in RAM. Interrupt vector table and critical interrupt handler too. I need to write EEPROM and serve critical interrupt at the same time. Before writing to the EEPROM all interrupts are disabled excepting one critical.

This approach works perfectly. I've checked critical interrupt presence by scope during EEPROM writing and EEPROM content afterwards.

Then I added USB VCP driver provided by ST. I've discovered that program was stalled during EEPROM writing. Critical interrupt doesn't appear at this time. Why? USB interrupts are disabled before EEPROM writing.

How can USB driver affects to the memory bank? Any ideas are welcome. Thanks.
    This topic has been closed for replies.

    2 replies

    tsuneo
    Associate II
    June 5, 2013
    Posted on June 05, 2013 at 19:52

    Are you working on STM32_USB-FS-Device_Lib_V4.0.0 (STSW-STM32081) ?

    The default Suspend/Resume behavior of the USB device stack may disturb your process, as discussed on

    https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/USB%20CDC%20on%20STM32L%20device%20%20unable%20to%20connect%20to%20host

    topic.

    The Suspend() code (in usb_pwr.c) of this stack drops the entire system into STOP mode. By this code, the device stays in STOP mode, while USB is not plugged in, and until bus reset occurs on USB after plug in.

    Temporarly, drop CNTR_SUSPM and CNTR_ESOFM from IMR_MSK() definition in usb_conf.h, as described on above post, to disable this behavior.

    Tsuneo

    glinsky
    glinskyAuthor
    Associate
    June 6, 2013
    Posted on June 06, 2013 at 08:28

    Hi!

    Thank you so much. It works as assumed now!

    Yes, I'm using STM32_USB-FS-Device_Lib_V4.0.0.

    I know about Suspend, I tried to prevent going to Suspend by setting

    __IO bool fSuspendEnabled = FALSE;  /* true when suspend is possible */

    and I thought that it's OK. The device shouldn't going to low power mode at this stage of development and has to operate without USB plugging.