Problema con USB en LPCXpressoo (LPC1769)

291 views
Skip to first unread message

gomezax...@gmail.com

unread,
Apr 5, 2021, 10:41:55 PM4/5/21
to Embebidos32

Buenas noches,

Estamos haciendo Proyecto Final para Ingeniería Electrónica en UTN FRA y se nos presentó un problema al querer utilizar USB con el LPCXpresso (el cual ya había utilizado con USB para otro proyecto en el año 2017).

Estoy utilizando LPCXpresso v8.2.2_650 compilando código de ejemplo de LPCOpen (v2.10) de los siguientes proyectos (sin editar):
  • usbd_lib_hid_generic
  • usbd_lib_hid_keyboard
  • usbd_lib_hid_mouse
En ninguno de los ejemplos (habiendo importado los proyectos base lpc_chip_175x_6x y lpc_board_nxp_lpcxpresso_1769) me funciona el USB una vez que compilo, debugueo e intento conectar los pines 36 y 37 (Data+ y Data -) (y GND) a un conector USB Mini como el de la foto adjunta al final de este mensaje.
El problema puntual que encuentro depurando el código es que cuando no hay nada conectado al USB el LPC siempre ingresa a la función de:
void USB_IRQHandler(void)
{
    USBD_API->hw->ISR(g_hUsb);
}

Una vez que conecto los pines al USB de la PC (por medio de un cable USB a MiniUSB) el LPC entra al handler una sola vez y luego se queda en el ciclo del while (1) del main.
En ese momento intento listar los USBs disponibles en mi PC y resulta que no veo listado el dispositivo que corresponde.
Una vez que se desconecta, se repite el mismo funcionamiento.

El Vendor | ID esperado es (según hid_desc.c):
ALIGNED(4) const uint8_t USB_DeviceDescriptor[] = {
    ....
    WBVAL(0x1FC9),                    /* idVendor */
    WBVAL(0x0086),                    /* idProduct */
    ....
}
Lo que claramente, no figura en la salida de lsusb:
Bus 001 Device 003: ID 04f2:b2da Chicony Electronics Co., Ltd
Bus 003 Device 004: ID 1fc9:001d NXP Semiconductors
Bus 001 Device 005: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 8086:1e31 Intel Corp.
Bus 003 Device 002: ID 04f2:0402 Chicony Electronics Co., Ltd Genius LuxeMate i200 Keyboard
Bus 001 Device 001: ID 8086:1e2d Intel Corp.
Bus 003 Device 001: ID 8086:1e26 Intel Corp.
Bus 003 Device 002: ID 04f2:0402 Chicony Electronics Co., Ltd Genius LuxeMate i200 Keyboard
Bus 003 Device 003: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 002: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
Bus 001 Device 006: ID 04d9:fc39 Holtek Semiconductor, Inc.
Bus 001 Device 002: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
Bus 001 Device 006: ID 04d9:fc39 Holtek Semiconductor, Inc.


El único dispositivo de NXP que figura es que conecto para compilar/depurar el LPCXpresso (el cual tiene otro ID al del descriptor de hid_desc.c)

Un último detalle que me parece correcto mencionar es que al compilar el proyecto usbd_lib_hid_keyboard en la línea 215 del hid_keyboard.c donde se verifica el estado del puerto:
    if ( USB_IsConfigured(g_keyBoard.hUsb)) {
Dicha función me lleva al usbd_core.h del lpc_chip_175x_6x/inc/usbd:
static INLINE bool USB_IsConfigured(USBD_HANDLE_T hUsb)
{
    USB_CORE_CTRL_T* pCtrl = (USB_CORE_CTRL_T*) hUsb;
    return (bool) (pCtrl->config_value != 0);   
}


Finalmente si desde ahí verifico el estado de pCtrl->config_value efectivamente termina siendo siempre 0.
Tampoco estaría encontrando la descripción de cada variable de la estructura USB_CORE_CTRL_T

Ya que la misma se declara de la siguiente forma (en usbd_core.h):
/* USB core controller data structure */
struct _USB_CORE_CTRL_T
{
  /* override-able function pointers ~ c++ style virtual functions*/
  USB_CB_T USB_EvtSetupHandler;
  USB_CB_T USB_EvtOutHandler;
  USB_PARAM_CB_T USB_ReqVendor;
  USB_CB_T USB_ReqGetStatus;
  USB_CB_T USB_ReqGetDescriptor;
  USB_CB_T USB_ReqGetConfiguration;
  USB_CB_T USB_ReqSetConfiguration;
  USB_CB_T USB_ReqGetInterface;
  USB_CB_T USB_ReqSetInterface;
  USB_PARAM_CB_T USB_ReqSetClrFeature;

  /* USB Device Events Callback Functions */
  USB_CB_T USB_Reset_Event;
  USB_CB_T USB_Suspend_Event;
  USB_CB_T USB_Resume_Event;
  USB_CB_T USB_SOF_Event;
  USB_PARAM_CB_T USB_Power_Event;
  USB_PARAM_CB_T USB_Error_Event;
  USB_PARAM_CB_T USB_WakeUpCfg;

  /* USB Core Events Callback Functions */
  USB_CB_T USB_Configure_Event;
  USB_CB_T USB_Interface_Event;
  USB_CB_T USB_Feature_Event;

  /* cache and MMU translation functions */
  uint32_t (* virt_to_phys)(void* vaddr);
  void (* cache_flush)(uint32_t* start_adr, uint32_t* end_adr);

  /* event handlers for endpoints. */
  USB_EP_HANDLER_T  ep_event_hdlr[2 * USB_MAX_EP_NUM];
  void*  ep_hdlr_data[2 * USB_MAX_EP_NUM];

  /* USB class handlers */
  USB_EP_HANDLER_T  ep0_hdlr_cb[USB_MAX_IF_NUM];
  void*  ep0_cb_data[USB_MAX_IF_NUM];
  uint8_t num_ep0_hdlrs;
  /* USB Core data Variables */
  uint8_t max_num_ep; /* max number of endpoints supported by the HW */
  uint8_t device_speed;
  uint8_t  num_interfaces;
  uint8_t  device_addr;
  uint8_t  config_value;
  uint16_t device_status;
  uint8_t *device_desc;
  uint8_t *string_desc;
  uint8_t *full_speed_desc;
  uint8_t *high_speed_desc;
  uint8_t *device_qualifier;
  uint32_t ep_mask;
  uint32_t ep_halt;
  uint32_t ep_stall;
  uint8_t  alt_setting[USB_MAX_IF_NUM];
  /* HW driver data pointer */
  void* hw_data;

  /* USB Endpoint 0 Data Info */
  USB_EP_DATA EP0Data;

  /* USB Endpoint 0 Buffer */
  //ALIGNED(4)
  uint8_t  EP0Buf[64];

  /* USB Setup Packet */
  //ALIGNED(4)
  USB_SETUP_PACKET SetupPacket;

};


Por todo lo anteriormente mencionado, paso a detallar las alternativas que propuse para resolver el inconveniente.

Ya se probó:
  1. Cambio de cable Mini USB
  2. Cambio del puerto en el cual se conecta a la PC 
  3. Distinto Sistema Operativo (Windows 10 y Ubuntu 16.04) para ver si lo reconoce, pero sin éxito.
  4. Nuevo workspace en LPC con ejemplos de LPCOpen sin modificar
  5. Una nueva placa (versión 1 y 2 en fotos). La versión 1 la hice sin pensar mucho en mantener Data+ y Data- del mismo largo (por su funcionar diferencial), por eso hice la versión 2. Pero tampoco obtuve resultados.
  6. Intercambiar Data+ con Data- en conexión desde LPCXpresso hasta el conector MiniUSB por temor a haber conectado mal (aunque según el datasheet está bien y según el proyecto del 2017 que hice está igual)
  7. Desconexión de la fuente de la PC (notebook) del tomacorriente (ante un eventual problema de masas)
  8. Instalar MCUXpresso IDE ya que es el que recomienda NXP y probar los códigos de ejemplo arriba mencionados (para todos el mismo resultado, no reconoce la PC el LPC por USB)
  9. Alimentar la placa de forma externa para que la única conexión a la PC sea la del cable MiniUSB.
Falta por probar:
  1. Realizar una placa con ruteado de cobre y evitar el trazado por estaño.
  2. Compilar con una versión muy similar a la utilizada en el 2017 (creo que era una versión 7 del IDE)

Estaría agotando todas las opciones aunque me inclinaría a pensar que es un problema de hardware.

Adjunto fotos de los conectores utilizados.

Primera versión
1.JPG
En la segunda foto el pin de la tira de pines de la derecha en su parte superior está el pin #1 del LPCXpresso. Mientras que en la tira de pines de la izquierda en su parte superior se encuentra el pin #28 del LPCXpresso, teniendo el pin #36 conectado a Data- (no se aprecia bien en la foto) y el #37 conectado a Data+

Tal y como lo indica el esquemático del LPC:
3.JPG

Asimismo, la segunda versión del conector:
2.JPG
El conexionado es exactamente el mismo que el anterior.


Cualquier crítica es bienvenida.

Saludos

Sergio Adrián Lapilli

unread,
Apr 6, 2021, 7:22:22 AM4/6/21
to embeb...@googlegroups.com

Hola.

 

Las pistas de USB no solo tienen que tener la misma longitud sino que deben rutearse con 90 ohms de impedancia característica en modo diferencial (+- 15%). No respetar estas condiciones supone un pobre o nulo funcionamiento.

 

Por otro lado, no veo que estés conectando la señal VBus al LPC, ojo que hay ciertas restricciones en cuanto a la máxima tensión en VBus dependiendo o no de la presencia de VDD en el LPC.

 

No está la resistencia de 1.5K pull up a VDD en D+ o D- de acuerdo a si el LPC es un full bandwidth device  (pull up en D+) o low bandwidth device (pull up en D-). No se pueden utilizar las resistencias internas del puerto de pull up porque el host tiene resistencias pull down de 15K en D+ y D-

 

También te recomiendo que coloques las resistencias en serie de 33 ohms (si es SMD mejor) en D+ y D-

 

Otra cosa importante es el clock (aunque supongo que están usando una placa Arduino o similar que ya cumple con las especificaciones)

 

Lo mejor es ver los diagramas de conexión de la hoja de datos del LPC1769 y los requisitos de los cristales u osciladores a utilizar.

 

Saludos

 

Mg. Ing. Sergio Lapilli

 

Enviado desde Correo para Windows 10

 

De: gomezax...@gmail.com
Enviado: lunes, 5 de abril de 2021 11:41 p. m.
Para: Embebidos32
Asunto: [embeb32] Problema con USB en LPCXpressoo (LPC1769)

 

 

Buenas noches,

 

Estamos haciendo Proyecto Final para Ingeniería Electrónica en UTN FRA y se nos presentó un problema al querer utilizar USB con el LPCXpresso (el cual ya había utilizado con USB para otro proyecto en el año 2017).

 

Estoy utilizando LPCXpresso v8.2.2_650 compilando código de ejemplo de LPCOpen (v2.10) de los siguientes proyectos (sin editar):

  • usbd_lib_hid_generic
  • usbd_lib_hid_keyboard
  • usbd_lib_hid_mouse

En ninguno de los ejemplos (habiendo importado los proyectos base lpc_chip_175x_6x y lpc_board_nxp_lpcxpresso_1769) me funciona el USB una vez que compilo, debugueo e intento conectar los pines 36 y 37 (Data+ y Data -) (y GND) a un conector USB Mini como el de la foto adjunta al final de este mensaje.

El problema puntual que encuentro depurando el código es que cuando no hay nada conectado al USB el LPC siempre ingresa a la función de:

void USB_IRQHandler(void)
{
    USBD_API->hw->ISR(g_hUsb);
}

 

Una vez que conecto los pines al USB de la PC (por medio de un cable USB a MiniUSB) el LPC entra al handler una sola vez y luego se queda en el ciclo del while (1) del main.

En ese momento intento listar los USBs disponibles en mi PC y resulta que no veo listado el dispositivo que corresponde.

Una vez que se desconecta, se repite el mismo funcionamiento.

 

El Vendor | ID esperado es (según hid_desc.c):

ALIGNED(4) const uint8_t USB_DeviceDescriptor[] = {

    ...

    WBVAL(0x1FC9),                    /* idVendor */
    WBVAL(0x0086),                    /* idProduct */

En la segunda foto el pin de la tira de pines de la derecha en su parte superior está el pin #1 del LPCXpresso. Mientras que en la tira de pines de la izquierda en su parte superior se encuentra el pin #28 del LPCXpresso, teniendo el pin #36 conectado a Data- (no se aprecia bien en la foto) y el #37 conectado a Data+

 

Tal y como lo indica el esquemático del LPC:

 

Asimismo, la segunda versión del conector:

El conexionado es exactamente el mismo que el anterior.

 

 

Cualquier crítica es bienvenida.

 

Saludos

 

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/a6166725-ad5d-4a5e-bd8c-47f9ea7441c6n%40googlegroups.com.

 

gomezax...@gmail.com

unread,
Apr 6, 2021, 3:37:49 PM4/6/21
to Embebidos32
Hola Sergio,

Como bien comentás claramente mi ruteado no es el ideal y entiendo estoy flaqueando en ese aspecto. En base a ello voy a probar conectar wirerap trenzado para evitar el estaño y sino, deberé ir al ruteado por cobre como prueba definitiva.

En cuanto al VBus realmente nunca lo utilicé. Yo podría alimentar al LPC mediante este

En cuanto a la resistencias lo bueno es que el kit LPCXpresso ya las provee:
1.JPG

Los pines USB-DP y USB-DM son los que terminan siendo conectados a la placa de la foto en mi primer mensaje.
Por otro lado el P2.9-USB_CONN es un pin que no termino utilizando y sé que tampoco lo utilicé en el 2017 cuando me funcionó debido a todavía veo ese pin de la placa sin soldar (es un pin que tiene el kit que no corresponde onc los típicos pines a los costados de un kit de desarrollo "común")

En lo referido al clock estoy casi seguro que cumple con las especificaciones por ser un kit bastante popular.

Gracias por la pronta respuesta.
Si llego a tener alguna noticia (tanto mala como buena) aviso.

Saludos

Sergio Adrián Lapilli

unread,
Apr 6, 2021, 4:32:19 PM4/6/21
to embeb...@googlegroups.com

Hola,

 

Si no usas VBus, asegúrate que el registro PINSEL de ese pin (no recuerdo cuál es) debe estar en 00. Esto hace que el sensor de conectado VBus esté siempre en 1.

 

Nunca es tarde para chequear los PINSEL de todas las señales de USB, pero chequeado con el debugger en el medio del programa. A veces, otra parte del programa pisa los registros y alteran el funcionamiento de los periféricos.

 

La resistencia de 1.5K debería estar conectada para que el host detecte el dispositivo, en este caso el pin de USB_CONN  -> PX.X=0. Al usar la señal USB_CONN podés controlar la conexión por software sin necesidad de desconectar el cable.

 

Podés probar a colocar una resistencia de 1.5K fija en el D- (y desactivar la señal USB_CONN, PX.X=1) para seleccionar menos velocidad y chequear si hay alguna mejora.

 

Saludos.

 

Sergio

 

 

 

 

Enviado desde Correo para Windows 10

 

De: gomezax...@gmail.com
Enviado: martes, 6 de abril de 2021 4:37 p. m.
Para: Embebidos32
Asunto: Re: [embeb32] Problema con USB en LPCXpressoo (LPC1769)

 

Hola Sergio,

 

Como bien comentás claramente mi ruteado no es el ideal y entiendo estoy flaqueando en ese aspecto. En base a ello voy a probar conectar wirerap trenzado para evitar el estaño y sino, deberé ir al ruteado por cobre como prueba definitiva.

 

En cuanto al VBus realmente nunca lo utilicé. Yo podría alimentar al LPC mediante este

 

En cuanto a la resistencias lo bueno es que el kit LPCXpresso ya las provee:

En la segunda foto el pin de la tira de pines de la derecha en su parte superior está el pin #1 del LPCXpresso. Mientras que en la tira de pines de la izquierda en su parte superior se encuentra el pin #28 del LPCXpresso, teniendo el pin #36 conectado a Data- (no se aprecia bien en la foto) y el #37 conectado a Data+

 

Tal y como lo indica el esquemático del LPC:

 

Asimismo, la segunda versión del conector:

El conexionado es exactamente el mismo que el anterior.

 

 

Cualquier crítica es bienvenida.

 

Saludos

 

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/a6166725-ad5d-4a5e-bd8c-47f9ea7441c6n%40googlegroups.com.

 

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

gomezax...@gmail.com

unread,
Apr 13, 2021, 12:16:06 AM4/13/21
to Embebidos32
Bueno,

Finalmente nos anduvo:
8.jpg

Cuya salida de lsusb:
Bus 001 Device 005: ID 04f2:b2da Chicony Electronics Co., Ltd

Bus 003 Device 004: ID 1fc9:001d NXP Semiconductors
Bus 001 Device 003: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 002 Device 001: ID 8086:1e31 Intel Corp.
Bus 003 Device 002: ID 04f2:0402 Chicony Electronics Co., Ltd Genius LuxeMate i200 Keyboard
Bus 001 Device 001: ID 8086:1e2d Intel Corp.
Bus 003 Device 001: ID 8086:1e26 Intel Corp.
Bus 003 Device 005: ID 1fc9:0081 NXP Semiconductors

Bus 003 Device 002: ID 04f2:0402 Chicony Electronics Co., Ltd Genius LuxeMate i200 Keyboard
Bus 003 Device 003: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 002: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
Bus 001 Device 004: ID 04d9:fc39 Holtek Semiconductor, Inc.

Bus 001 Device 002: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
Bus 001 Device 004: ID 04d9:fc39 Holtek Semiconductor, Inc.


Y no era problema de hardware y ahora comento por qué. Seguramente le sirva a a alguno en el futuro....

Da la casualidad (tenía un vano recuerdo de cuando nos había funcionado) que la biblioteca LPCOpen 2.10 (versión actual la cual NPX no actualiza desde el 12/3/2014 => remitirse al lpcopen_2_10_lpcxpresso_nxp_lpcxpresso_1769.zip de la última versión de MCUXpresso que la incluye) en el archivo src/board.c del proyecto lpc_board_nxp_lpcxpresso_1769 en la línea 358:
void Board_USBD_Init(uint32_t port)
{
    /* VBUS is not connected on the NXP LPCXpresso LPC1769, so leave the pin at default setting. */
    /*Chip_IOCON_PinMux(LPC_IOCON, 1, 30, IOCON_MODE_INACT, IOCON_FUNC2);*/ /* USB VBUS */
    
    Chip_IOCON_PinMux(LPC_IOCON, 0, 29, IOCON_MODE_INACT, IOCON_FUNC1);    /* P0.29 D1+, P0.30 D1- */
    Chip_IOCON_PinMux(LPC_IOCON, 0, 30, IOCON_MODE_INACT, IOCON_FUNC1);

    LPC_USB->USBClkCtrl = 0x12;                /* Dev, AHB clock enable */
    while ((LPC_USB->USBClkSt & 0x12) != 0x12);
}


Hay que agregarle una línea que configure el pin USB_CONNECT como función del USB (dicho pin pone a PullUp D+ el cual detallo con una imagen en un mensaje anterior de esta misma cadena) ya que la función default (00) es GPIO:
2.JPG

Con el agregado de esta configuración la función del board.c mencionada anteriormente resulta:
void Board_USBD_Init(uint32_t port)
{
    /* VBUS is not connected on the NXP LPCXpresso LPC1769, so leave the pin at default setting. */
    /*Chip_IOCON_PinMux(LPC_IOCON, 1, 30, IOCON_MODE_INACT, IOCON_FUNC2);*/ /* USB VBUS */
    
    Chip_IOCON_PinMux(LPC_IOCON, 0, 29, IOCON_MODE_INACT, IOCON_FUNC1);    /* P0.29 D1+, P0.30 D1- */
    Chip_IOCON_PinMux(LPC_IOCON, 0, 30, IOCON_MODE_INACT, IOCON_FUNC1);

    Chip_IOCON_PinMux(LPC_IOCON, 2, 9, IOCON_MODE_INACT, IOCON_FUNC1); /* SIN ESTO NO FUNCIONA */
    
    LPC_USB->USBClkCtrl = 0x12;                /* Dev, AHB clock enable */
    while ((LPC_USB->USBClkSt & 0x12) != 0x12);
}


Para detallar la función 01 del Pin el User Manual dice:
1.JPG


Espero que le sirva a alguien más que esté trabado con el mismo problema y no encuentre solución ya que esto no recuerdo haberlo visto en ningún foro ni en ningún lado, simplement con el hecho de leer y releer la documentación (y probar, mucho probar) lo pudimos resolver.

Quien iba a pensar que la biblioteca oficial del fabricante del kit (con el ejemplo oficial) iba a fallar en una configuración tan crucial como la de un pin.
Nota: Lo importante es que sin importar el proyecto que se utilice: hid_generic, hid_keyboard, hid_mouse; como todos comparten la misma dependencia del lpc_board, el modificarla influye en dichos proyectos (y todo aquel que la utilice).

Por si habían quedado dudas sobre el hardware utilizado, anduvo con este prototipo:
4.JPG

y este:
6.JPG

Conectado de la siguiente forma:
IMG_20210413_010354177.jpg
IMG_20210413_010348594.jpg

y hasta en esta otra conexión:
3.jpeg

Nada quita que siempre hay que seguir las buenas prácticas de adaptación y conexionado.
Aunque para nuestras pruebas iniciales de concepto, con lo demostrado anteriormente, nos alcanza.


Saludos
Reply all
Reply to author
Forward
0 new messages