Sleep mode y la USART2

35 views
Skip to first unread message

Emilio Moretti

unread,
May 24, 2020, 3:35:08 PM5/24/20
to Embebidos32
Buenas, consulta.
Tengo la USART2 no bloqueante corriendo y entro MUY seguido en sleep mode. El problema es que las interrupciones de la USART no están despertando el procesador, mientras que otras interrupciones sí (Timer1, y ATIMER lo despiertan sin problemas, y las uso para delays no bloqueantes). Como consecuencia el texto se envía muuuy lentamente (16 bytes de la cola de TX por vez), a medida que el procesador se va despertando.

Mi consulta es si se puede lograr que en el LPC4337 las interrupciones de la USART hagan salir al procesador del modo sleep, porque actualmente el texto unicamente cuando no estoy en sleep. Quizás algo con el EventRouter?

Estoy mirando el User Manual pero no lo encuentro. Encontré que varios procesadores de LPC no pueden despertarlo con la uart, pero también leí que hay otros que sí, y no encuentro la forma.

Todo esto es corriendo TockOS en la EDU-CIAA-NXP. Es un RTOS hecho en Rust, que ahora se hizo conocido porque lo usó google.
En algún momento lo presentaré oficialmente, pero por ahora les dejo el repositorio con buen soporte para nuestra querida edu-ciaa. Si alguno conoce el SO sabrá que también se necesita soporte en el tockloader, y con mucho gusto les cuento que eso ya fue mergeado al repositorio oficial.


Gracias!
Saludos

Juan Manuel Cruz Beaufrere

unread,
May 26, 2020, 11:07:39 AM5/26/20
to embeb...@googlegroups.com

En el Product data sheet LPC435x/3x/2x/1x página 64 detalla:

  • Remark: Any interrupt can wake up the ARM Cortex-M4 from sleep mode if enabled in the NVIC.

En tu lugar revisaría:

  • si la IRQ de Rx se genera correctamente sin entrar a modo Sleep
  • si la IRQ de Tx se genera correctamente sin entrar a modo Sleep
  • luego repetiría las pruebas entrando previamente a modo Sleep
  • y para simplificar la prueba con UART2 lo haría sobre alguno de los ejemplos de sAPI que Tx/Rx por interrupciones
  • si la IRQ de Rx saca al uC de modo Sleep y IRQ de Tx no lo hace, revisaría las condiciones de habilitación de la IRQ de Tx
  • si la IRQ de Rx no saca al uC de modo Sleep, :-( 
-- 
Ing. Juan Manuel Cruz

E-mail: juanmanuelc...@gmail.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.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/ac3ed1e0-63c8-4b8a-9dda-cb67d280c216%40googlegroups.com.

Emilio Moretti

unread,
May 26, 2020, 7:01:10 PM5/26/20
to Embebidos32
Gracias Juan. Yo pensaba lo mismo. Es más, en el datasheet dice que las interrupciones la levantan del sleep...

Remark: Any interrupt can wake up the ARM Cortex-M4 from sleep mode if enabled in the NVIC.

El datasheet dice eso en la sección del event router.

sin embargo después de mucho testear llegué a la conclusión de que quizás no se podía o que solamente eran las interrupciones que podían llegar al event router. Busqué en internet y parece que hay varios micros en la misma problemática.

Por las dudas pregunté en la comunidad de nxp, y un empleado me confirmó que la interrupción de la USART no despierta el micro del lpc4337:


Así que ahora lo que tengo que hacer es buscar la forma de que no vaya a sleep si hay transacciones de la USART pendientes. Un hack bastante feo la verdad.

Saludos y gracias de todas formas.

On Tuesday, May 26, 2020 at 12:07:39 PM UTC-3, juanmanuelcruzbeaufrere wrote:

En el Product data sheet LPC435x/3x/2x/1x página 64 detalla:

  • Remark: Any interrupt can wake up the ARM Cortex-M4 from sleep mode if enabled in the NVIC.

En tu lugar revisaría:

  • si la IRQ de Rx se genera correctamente sin entrar a modo Sleep
  • si la IRQ de Tx se genera correctamente sin entrar a modo Sleep
  • luego repetiría las pruebas entrando previamente a modo Sleep
  • y para simplificar la prueba con UART2 lo haría sobre alguno de los ejemplos de sAPI que Tx/Rx por interrupciones
  • si la IRQ de Rx saca al uC de modo Sleep y IRQ de Tx no lo hace, revisaría las condiciones de habilitación de la IRQ de Tx
  • si la IRQ de Rx no saca al uC de modo Sleep, :-( 
-- 
Ing. Juan Manuel Cruz

E-mail: juanmanuelc...@gmail.com
El 24/05/2020 a las 04:35 p. m., Emilio Moretti escribió:
Buenas, consulta.
Tengo la USART2 no bloqueante corriendo y entro MUY seguido en sleep mode. El problema es que las interrupciones de la USART no están despertando el procesador, mientras que otras interrupciones sí (Timer1, y ATIMER lo despiertan sin problemas, y las uso para delays no bloqueantes). Como consecuencia el texto se envía muuuy lentamente (16 bytes de la cola de TX por vez), a medida que el procesador se va despertando.

Mi consulta es si se puede lograr que en el LPC4337 las interrupciones de la USART hagan salir al procesador del modo sleep, porque actualmente el texto unicamente cuando no estoy en sleep. Quizás algo con el EventRouter?

Estoy mirando el User Manual pero no lo encuentro. Encontré que varios procesadores de LPC no pueden despertarlo con la uart, pero también leí que hay otros que sí, y no encuentro la forma.

Todo esto es corriendo TockOS en la EDU-CIAA-NXP. Es un RTOS hecho en Rust, que ahora se hizo conocido porque lo usó google.
En algún momento lo presentaré oficialmente, pero por ahora les dejo el repositorio con buen soporte para nuestra querida edu-ciaa. Si alguno conoce el SO sabrá que también se necesita soporte en el tockloader, y con mucho gusto les cuento que eso ya fue mergeado al repositorio oficial.


Gracias!
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 embeb...@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 embeb...@googlegroups.com.

Juan Manuel Cruz Beaufrere

unread,
May 27, 2020, 7:20:48 AM5/27/20
to embeb...@googlegroups.com

De nada Emilio, sólo te copié la línea Remark de la hoja de datos del uC.

El User manual del uC es muy claro, respecto a qué periféricos pueden asociarse a "event router" y lamentablemente las UART no están entre tales periféricos.

Por eso te recomendé probar si al recibir un caracter por UART se genera la IRQ y ésta puede sacar al uC de modo sleep. ¿Llegaste a hacer ésta prueba?

-- 
Ing. Juan Manuel Cruz

E-mail: juanmanuelc...@gmail.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.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/0cbf9421-a865-47f4-9cc3-70184dd9b0e4%40googlegroups.com.

Emilio Moretti

unread,
May 27, 2020, 8:28:59 AM5/27/20
to Embebidos32
Hola Juan,
ante todo disculpas por el email anterior, me salió a las apuradas, no lo leí dos veces, y repito basicamente lo que me comentás vos.

Justamente probando eso encontré el problema. En el kernel no hay forma de implementar una uart bloqueante a menos que uno escriba algunos hacks a mano, pero en mi port unicamente existe el código para que funcione por interrupciones. Lo tuve que solucionar donde el kernel llama a WFI. Si hay colas de datos para enviarse NO se pone en sleep hasta que no termine de enviar los datos, y con eso funciona bien. Ahora el interrupt se dispara, y la transmisión continúa hasta que el buffer se vacía, y el kernel ahí sí llama a WFI.

Una pena realmente, pero al menos el fix no fue complicado.

Gracias por la ayuda de todas formas
Saludos
Reply all
Reply to author
Forward
0 new messages