freertos and uart

[lpcware]

Content originally posted in LPCWare by dragilla on Wed Dec 07 14:16:16 MST 2011
Can I have an uart running in interrupt mode and freertos on one device?
I tried and got hard fault, some interrupt collision...
Or maybe I should create a task where I will read uart in polling mode and give it low priority?

[lpcware]

Content originally posted in LPCWare by dandumit on Wed Aug 19 22:34:01 MST 2015
Thank you Polux for example. For me it's relevant and instructive.
By the way do you have an updated version of serial lib ?

[lpcware]

Content originally posted in LPCWare by Polux rsv on Thu Dec 08 14:24:42 MST 2011
My e-mail is down. So, here are the files for those interested.
It is not an example of clarity and coding. :D  But it works.
The gps.c file is still under development, but the others are quite good.

[ATTACH]625[/ATTACH]

Angelo

[lpcware]

Content originally posted in LPCWare by dragilla on Thu Dec 08 04:35:56 MST 2011
my_nick at gmail dot com
thanks!

[lpcware]

Content originally posted in LPCWare by Polux rsv on Thu Dec 08 02:49:23 MST 2011
Dragilla, send me again your e-mail address, I will send you my project which is based on Freertos, with uart drivers using interrupts and Freertos to handle transmit and receive buffers .

Angelo

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Dec 08 02:27:28 MST 2011
Just checked my app.

You should not start the SysTick timer.
This is done by xPortStartScheduler() in port.c after initializing the variables that are needed by FreeRTOS (xPortStartScheduler is called from vTaskStartScheduler).
This function then calls prvSetupTimerInterrupt() to program and start the SysTick timer.

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Dec 08 02:17:23 MST 2011
Then there is a problem with the order of initialization.
I see that the xPortSysTickHandler is being called.

This handler call vTaskIncrementTick() (in tasks.c) and this is the part of the FreeRTOS scheduler that checks the tasklists to see if a task switch is needed.
So you are actually asking the scheduler to check for something that is not yet initialized.

Rob

[lpcware]

Content originally posted in LPCWare by dragilla on Thu Dec 08 02:10:26 MST 2011
Only this error occurs before I even create tasks. It's just a call to uart_init at almost the beginning of my main function. And it is a working code copied from my non-freertos app.

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Dec 08 01:13:35 MST 2011

---

Quote: dragilla
Can I have an uart running in interrupt mode and freertos on one device?

---

Yes you can. I have multiple UARTs running in interrupt mode in my FreeRTOS app.

---

Quote: ArneB
Divsion by 0 error ?    

---

Nope.
Have a look at the first piece of __aeabi_uldivmod():

                               __aeabi_uldivmod:
00005b16: __aeabi_uldivmod+0     movs.w r12, #0
00005b1a: __aeabi_uldivmod+4     push {r4, r5, lr}
00005b1c: __aeabi_uldivmod+6     movs r4, r3
00005b1e: __aeabi_uldivmod+8     bne.n 0x5b66 <ldiv64>
00005b20: __aeabi_uldivmod+10    movs r2, r2
00005b22: __aeabi_uldivmod+12    beq.n 0x5c04 <ldiv_divzero>
00005b24: __aeabi_uldivmod+14    cmp r1, r2
00005b26: __aeabi_uldivmod+16    bcc.n 0x5b36 <ldiv32>
00005b28: __aeabi_uldivmod+18    mov r5, r0
00005b2a: __aeabi_uldivmod+20    mov r0, r1
00005b2c: __aeabi_uldivmod+22    movs r1, #0
00005b2e: __aeabi_uldivmod+24    bl 0x5c10 <udiv6432>

The code is trying to do a division of r1.r0 by r3.r2 (both 64 bit numbers).
The first check is to see if r3 is zero. If it is, ldiv32 is used to do an r1.r0/r2
The second check is to see if r2 is zero. If it is, the jump to ldiv_divzero just sets the result to 0.

So there is no division by zero interrupt at all.
This results in the same behavior as the uldiv instruction: a div by zero just results in a zero result.
Also, there are more lines above the uldivmod() (xPortSysTickHandler and xPostPendSVhandler) that point me in the direction of FreeRTOS as the target of the hardfault.

Please note that I am writing [I]target[/I] of the fault, not the [I]source[/I] of the fault ...
The source of the fault is most likely within your own application. You could try to use the OpenRTOS Viewer to have a look at your task structures. It is most likely that you will see that you have a stack overflow on your task resulting in a corrupt entry in the task table.
Please have a look at [U]this page[/U], it contains some hints on how to use the OpenRTOS Viewer and locating the fault.
Only after :rolleyes: having seen this, enlarge your stack size and test again.

Regards,[INDENT]Rob
[/INDENT]

[lpcware]

Content originally posted in LPCWare by DaveNadler on Wed Dec 07 18:36:54 MST 2011
More specifically, division-by-zero at lpc17xx_uart.c:110 ?

[lpcware]

Content originally posted in LPCWare by ArneB on Wed Dec 07 15:31:53 MST 2011

---

Quote:
5 __aeabi_uldivmod()  0x0000963c

---

Divsion by 0 error ?

[lpcware]

Content originally posted in LPCWare by dragilla on Wed Dec 07 15:18:42 MST 2011
Hm, It's the Uart_Init that is causing the hard fault... I think.

tcl-freertos Debug [C/C++ MCU Application]
MCU GDB Debugger (12/7/11 11:11 PM) (Suspended)
Thread [1] (Suspended: Signal 'SIGSTOP' received. Description: Stopped (signal).)
11 HardFault_Handler() cr_startup_lpc17.c:301 0x0000027c
10 <signal handler called>()  0xfffffff1
9 xPortPendSVHandler() port.c:224 0x00006ec8
8 <signal handler called>()  0xfffffff1
7 xPortSysTickHandler() port.c:264 0x00006f14
6 <signal handler called>()  0xfffffff9
5 __aeabi_uldivmod()  0x0000963c
4 uart_set_divisors() lpc17xx_uart.c:110 0x000039f4
3 UART_Init() lpc17xx_uart.c:315 0x00003e88
2 setupHardware() main.c:155 0x000045f2
1 main() main.c:637 0x00005eb2
arm-none-eabi-gdb (12/7/11 11:11 PM)
/home/luke/Desktop/moje/work/workspace/tcl-freertos/Debug/tcl-freertos.axf (12/7/11 11:11 PM)