Device not Recognized during Bootloader Execution

0	Device not Recognized during Bootloader Execution Issue Report - Created by Robert on 2/2/2015 12:51:01 PM Actions Edit Properties Close Ticket Delete Ticket

Robert

Posted

9 years ago

Using Dynetics hardware. This hardware has been utilized successfully with another USB driver, so, I feel confident of its design. I have modified usbhal.h to utilize USB Port Number 1 (USB_PORT 1). After this change, I started taking 1 USB_IRQHANDLER() interrupt. During servicing of this interrupt, __CHECK_BIT(status, 4) is truce, and the USBResetHAL(); routine is called. No additional interrupts occur.

I am using Keil uVision V4.72.10.0.

Rob

Tyler

DZX Support

Posted

9 years ago

Hello Rob,

We may need a bit more information. Is the device ever enumerating properly? Or is this a problem that occurs when a switch to the bootloader is performed (the usb is disconnected and then reconnected)?

Something to verify would be the pin/signal that is used to place the pull-up on the USB D+ line. When USB_PORT is set to '1', the usbhal.c configures pin 0.14 to be the USB_CONNECT2 function. Is that the appropriate pin for your hardware?

-Tyler

Robert

Posted

9 years ago

Thanks Tyler for the quick reply. I went back through my old project and noticed that I had to add control of the soft connect discrete to the USBSetConnectCtrl routine. I am now able to detect the device.

/* Command to enable the soft connect */
USBWriteSIE(USBPORT_SIE_CMD_SET_DEVICE_STATUS, 0x01);

#ifdef USB_USE_GPIO_SOFT_CONNECT

   LPC_GPIO2->SET = 0x00000200;

#endif
}
else
{

/* Command to release the soft connect */
USBWriteSIE(USBPORT_SIE_CMD_SET_DEVICE_STATUS, 0x00);

#ifdef USB_USE_GPIO_SOFT_CONNECT
LPC_GPIO2->CLR = 0x00000200;

Things go awry when I jump to the application from the bootloader. I noticed in the old project (LPC2468) that you were relocating the interrupt vectors to high RAM.

#define USBPORT_REG_VIC_BASE   0xFFFFF000

However, I do not see this in the bootloader for the LPC1788. Has your methodology changed?

Rob

Tyler

DZX Support

Posted

9 years ago

Rob,

The LPC17XX (and all Cortex-M) supports the ability to re-map the vector table to anywhere within the flash array, so copying the vector table into RAM is no longer required on these MCU's. It is controlled via the Vector Table Offset Register (VTOR).

The USBPort demo uses the define USBPORT_REG_VTOR to configure the location of the vector table. It's one of the first things that happens within main.c of both the user and bootloader applications.

Let me know if I can be of further help.
-Tyler

Robert

Posted

9 years ago

Tyler,

Again, I must commend you on your rapid and accurate response. It is much appreciated! All seems to be working well with boot and app. I did decrease the USBPORT_REG_WDTC and the BOOT_APPLICATION_SWITCH_LOOP_DELAY values to decrease the time of recognisinze the switch from boot to app and vice versa.

Have a great day!

Rob