Bitcraze Forums

I am trying to enable UART1 for debug prints instead of having DEBUG_PRINT print through the radio or USB. In the crazyflie firmware I edited the Makefile and added

CFLAGS += -DENABLE_UART1
CFLAGS += -DDEBUG_PRINT_ON_UART

The code compiles and flashes to my CF 2.1. But when I turn my CF 2.1 on, it does not boot all the way and issues an assert_fail and rests itself.
I have connected UART1 pins to a FTDI board and then the FTDI usb is connected to my PC. The repeated text I receive over UART1 is:
SYS: Crazyflie 2.1 is up and running!
SYS: Build 0:8d02f4730e00 (NA) MODIFIED
SYS: SYS: Assert failed .//vendor/FreeRTOS/queue.c:132SYS: ----------------------------

It seems that it is having trouble with the line of code
DEBUG_PRINT("I am 0x%08X%08X%08X and I have %dKB of flash!\n",
*((int*)(MCU_ID_ADDRESS+8)), *((int*)(MCU_ID_ADDRESS+4)),
*((int*)(MCU_ID_ADDRESS+0)), *((short*)(MCU_FLASH_SIZE_ADDRESS)));
in the function systemInit(void).
If I comment out this DEBUG_PRINT line the CF 2.1 boots a bit farther but still issues an assert_fail later in the boot path.

I am trying to find away to debug the crazyflie firmware if errors occur before the radio is ready to connect to the cfclient and this UART1 way is almost working for my purpose. Is there a memory size I need to increase for the UART1_DMA or something??

We have not tried this in a long time but I know it did work at some point. Could something be running out of memory?

In system.c, I changed the baud rate to 115200 and the CF boots all the way with no assertfails. Thinking about RAM issues when using DMA, made me think that the serial port was not sending fast enough and too many characters were being buffered. So by changing the baud rate maybe this does not happen? Anyway it seems to be working now.

Great! There is still a bug as it should be able to handle a overflow condition. This functionality is very seldom used I'm not sure it ever will be fixed though.