3

I'm currently encountering a strange issue with the STM USB libraries. I am able to successfully load firmware onto the STM32L152D-EVAL board (which uses an STM32L152ZD), however, I am unable to modify the same code to work on my form-factor board, which uses the aforementioned STM32L151CC.

After stepping through the code with the debugger (a ULINK2, using the KEIL uVision4 IDE), I noticed that the code would crash while setting the interrupt mask in the function USB_SIL_Init()

uint32_t USB_SIL_Init(void)
{
  /* USB interrupts initialization */
  /* clear pending interrupts */
  _SetISTR(0);
  wInterrupt_Mask = IMR_MSK;
  /* set interrupts mask */
  _SetCNTR(wInterrupt_Mask);
  return 0;
}

More specifically, _SetCNTR(wInterrupt_Mask); is what gives me the error. I haven't changed the value of IMR_MSK between either board. It's value is given as

#define IMR_MSK (CNTR_CTRM | CNTR_WKUPM | CNTR_SUSPM | CNTR_ERRM | CNTR_SOFM \ | CNTR_ESOFM | CNTR_RESETM )

which is 0xBF00

_SetCNTR is defined as follows

 #define _SetCNTR(wRegValue)  (*CNTR   = (uint16_t)wRegValue)

With CNTR being defined as

/* Control register */
#define CNTR    ((__IO unsigned *)(RegBase + 0x40))

And RegBase is

#define RegBase (0x40005C00L)  /* USB_IP Peripheral Registers base address */

I'm currently looking through STM's documentation on this, but I can't seem to find anything specifically relating to the default states for the two different chips. I'm guessing it has something to do with the base address, however the Datasheet shows that this is the correct address.

Can anyone help me out on this?

Thanks!

Tlacenka
  • 520
  • 9
  • 15
ThomSirveaux
  • 141
  • 1
  • 4
  • 2
    How dies it crash? Jump into the weeds? Can you put a breakpoint in the USB ISR? Is that being serviced? – Fiddling Bits Aug 07 '14 at 00:25
  • While stepping through the debugger, uVision tells me that it can no longer read from memory. As far as "jumping into the weeds," I can't say for sure. The code runs just fine on the EVAL board, but when I run on form-factor, weird little issues crop up. – ThomSirveaux Aug 07 '14 at 17:06
  • 1
    Long shot, but could you have code or interrupt vector data which fits in the 384K or the demo board part but not in the 256K of yours? Or a similar issue if the ram sizes are different? – Chris Stratton Aug 07 '14 at 20:30
  • @ChrisStratton I think that might be it. For right now, I'm switching to getting the other functionality to work. We have an in-house interrupt handler/Faux-S designed for similar boards. Once I return to the USB portion, I'll update as necessary. – ThomSirveaux Aug 07 '14 at 20:52

0 Answers0