Conversion from Chibios2.6.6 to Chibios16.1

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: barthess, RoccoMarco

Rick Burnett
Posts: 142
Joined: Tue Jan 08, 2013 2:20 pm

Conversion from Chibios2.6.6 to Chibios16.1

Postby Rick Burnett » Fri Apr 21, 2017 4:39 am

So I've spent an evening updating my code to a newer version. I was using TIM2 but I know that was needed by tickless mode so I switched to TIM5 (I need the 32-bit resolution).

Got everything to compile, loaded in the code, and now my display (LCD) updated INCREDIBLY slow, sometimes not at all. It's connected up through the RAM interface and I use DMA. Basically by display thread just runs at a lower priority and fills up RAM with a frame, then uses DMA to transfer to the display basically in the background.

Any idea why I would see that now working like 2.6.6?

Rick Burnett
Posts: 142
Joined: Tue Jan 08, 2013 2:20 pm

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby Rick Burnett » Fri Apr 21, 2017 6:56 am

Things I have tried and made no difference:

    Turned off tickless mode, and used quantum of 20 like I had in 2.6.6, no difference.
    Tried different frequency setting for tickless mode.
    Tried to use DMA1_STREAM6 but everything locked up.
    Changed the DMA priority on the ADC to same as I had in 2.6.6 since they both use DMA channel 2.
    Made sure all my priorities matched what I had in 2.6.6

Tried IRQ PRIORITY of 8 and then 2.

Code: Select all

#define STM32_ST_IRQ_PRIORITY               2
#define STM32_ST_USE_TIMER                  2



Code: Select all

#define GDISP_DMA_STREAM STM32_DMA2_STREAM6
rccEnableAHB3(RCC_AHB3ENR_FMCEN, 0);

   //setup some DMA stuff
   dmaStreamAllocate(GDISP_DMA_STREAM, 0, NULL, NULL);
   dmaStreamSetMemory0(GDISP_DMA_STREAM, &LCD_DATA);
   dmaStreamSetMode(GDISP_DMA_STREAM, STM32_DMA_CR_PL(0) | STM32_DMA_CR_PSIZE_HWORD | STM32_DMA_CR_MSIZE_HWORD | STM32_DMA_CR_DIR_M2M);
      

   // set pin modes
   IOBus busD = {GPIOD, (1 << 0) | (1 << 1) | (1 << 4) | (1 << 5) | (1 << 7) | (1 << 8) |
                     (1 << 9) | (1 << 10) | (1 << 11) | (1 << 14) | (1 << 15), 0};

   IOBus busE = {GPIOE, (1 << 7) | (1 << 8) | (1 << 9) | (1 << 10) | (1 << 11) | (1 << 12) |
                  (1 << 13) | (1 << 14) | (1 << 15), 0};
   
   palSetBusMode(&busD, PAL_MODE_ALTERNATE(12));
   palSetBusMode(&busE, PAL_MODE_ALTERNATE(12));
   //RESET PIN
   palSetPadMode(GPIOB, 11, PAL_MODE_OUTPUT_PUSHPULL);

    const unsigned char FMC_Bank = 0;

    /* FSMC timing */
    // -*- WORKING SETTINGS           ADDSET=6, DATASET=10, BUSTURN=10
    FMC_Bank1->BTCR[FMC_Bank+1] = (6) | (10 << 8) | (10 << 16);


That's how I setup the FMC.

Given it occasionally writes to the screen, sometimes bits of it are in the wrong place. That part just doesn't make any sense to me. The DISPLAY code is set to low priority. All I can think is something of higher priority must be getting called more than normal now and not leaving any time for the display thread. I do use virtual timers and a GPT to call code regularly. I slowed down the GPT call quite a bit, but no change. There are things that blink (LED) based of the GPT calls and they are working correctly.

Rick Burnett
Posts: 142
Joined: Tue Jan 08, 2013 2:20 pm

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby Rick Burnett » Fri Apr 21, 2017 7:23 am

Realized I could swap TIM2 and TIM5 for what ChibiOS is going to use for a clock, so switched all my code back, but didn't make a difference.

Shut off the ADC and the GPT code as well, still no difference.

Here is also the code for me writing to the LCD (I break it into chunks)

Code: Select all

void drawFrameBuffer ()
{
   //harcode test

   setAddrWindow(0,0,LCD_WIDTH,LCD_HEIGHT);
   writeLCDSetCursor(0,0);
   writeLCDStreamStart();

   dmaStreamSetPeripheral(GDISP_DMA_STREAM, frameBuffer);
   dmaStreamSetMode(GDISP_DMA_STREAM, STM32_DMA_CR_PL(0) | STM32_DMA_CR_PINC | STM32_DMA_CR_PSIZE_HWORD | STM32_DMA_CR_MSIZE_HWORD | STM32_DMA_CR_DIR_M2M);
   
   dmaStreamSetTransactionSize(GDISP_DMA_STREAM, 65535);
   dmaStreamEnable(GDISP_DMA_STREAM);
   dmaWaitCompletion(GDISP_DMA_STREAM);

   dmaStreamSetPeripheral(GDISP_DMA_STREAM, frameBuffer+65535);
   dmaStreamSetMode(GDISP_DMA_STREAM, STM32_DMA_CR_PL(0) | STM32_DMA_CR_PINC | STM32_DMA_CR_PSIZE_HWORD | STM32_DMA_CR_MSIZE_HWORD | STM32_DMA_CR_DIR_M2M);
   dmaStreamSetTransactionSize(GDISP_DMA_STREAM, FB_SIZE - 65535);
   dmaStreamEnable(GDISP_DMA_STREAM);
   dmaWaitCompletion(GDISP_DMA_STREAM);

   
}

User avatar
RoccoMarco
Posts: 553
Joined: Wed Apr 24, 2013 4:11 pm
Location: Salerno (Italy)
Has thanked: 64 times
Been thanked: 49 times
Contact:

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby RoccoMarco » Fri Apr 21, 2017 7:47 am

Hi,
is that function called periodically in a thread or is when a dma interrupt is fired?

Edit:
BTW i suppose you have copied a new demo and edited it. Check threads and irq priority in main and mcuconf
Ciao,
RM

Rick Burnett
Posts: 142
Joined: Tue Jan 08, 2013 2:20 pm

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby Rick Burnett » Fri Apr 21, 2017 7:57 am

Basically what happens is the display loop runs in a low priority thread. So whenever the processor has free time, it builds a frame. Then when it is done, it calls the function to draw it which sends it out DMA and waits till it is done.

I did copy (created a branch) and have checked all settings between the two, they are the same in terms of interrupts and DMA channels. Even shutting off everything made no difference.

What I am doing now is turning on all the debug options to see if I can find something I missed. Seems to run still and not asserting any errors yet (other than not working right)

Rick Burnett
Posts: 142
Joined: Tue Jan 08, 2013 2:20 pm

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby Rick Burnett » Fri Apr 21, 2017 8:01 am

Enabling all the debug options causes it to halt now, so that's probably a good sign in that something is wrong. Although not sure how to debug what is causing the problem

Code: Select all

 #0  0x0802e2c0 in chSysHalt (reason=0x8054f10 <__func__.9116.lto_priv.160> "gpt_lld_start")
    at /Users/grimepoch/mac-build/ChibiOS/os/rt/src/chsys.c:181
#1  0x08029318 in gpt_lld_start (gptp=0x20001964 <GPTD2>)
    at /Users/grimepoch/mac-build/ChibiOS/os/hal/ports/STM32/LLD/TIMv1/gpt_lld.c:676
#2  0x0802cef0 in gptStart (gptp=0x20001964 <GPTD2>, config=0x20000b50 <gpt2cfg.lto_priv.4>)
    at /Users/grimepoch/mac-build/ChibiOS/os/hal/src/gpt.c:90
#3  0x0800199e in main () at main.c:8220
Last edited by Rick Burnett on Fri Apr 21, 2017 8:17 am, edited 1 time in total.

User avatar
RoccoMarco
Posts: 553
Joined: Wed Apr 24, 2013 4:11 pm
Location: Salerno (Italy)
Has thanked: 64 times
Been thanked: 49 times
Contact:

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby RoccoMarco » Fri Apr 21, 2017 8:10 am

In chibistudio there is a debug plugin which allow to explore debug info. BTW take a look in the code window the reason is saved in a structure named ch. It should be ch.panicmsg.

It is a code... there are some article in chibios.org about debugging.
Ciao,
RM

Rick Burnett
Posts: 142
Joined: Tue Jan 08, 2013 2:20 pm

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby Rick Burnett » Fri Apr 21, 2017 8:18 am

I updated the above post with the information after recompiling with -O0 so things weren't optimized away.

This isn't in ChibiStudio, all my work is in command line.

Rick Burnett
Posts: 142
Joined: Tue Jan 08, 2013 2:20 pm

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby Rick Burnett » Fri Apr 21, 2017 8:27 am

Interesting,

So I took out all the code that was initializing the GPT2 timer (And it's callbacks) because that is what is causing the halt.

Now the display works! So something to do with the timer. Too late tonight to finish debugging but at least one step closer. Haha. Not sure what changed with TIM2 that is causing it to fail. Maybe there is more needed in the configuration now. Just not sure.

Rick Burnett
Posts: 142
Joined: Tue Jan 08, 2013 2:20 pm

Re: Conversion from Chibios2.6.6 to Chibios16.1

Postby Rick Burnett » Sun Jul 09, 2017 8:16 pm

Found out why it was halting, was this line:

Code: Select all

  osalDbgAssert(((uint32_t)(psc + 1) * gptp->config->frequency) == gptp->clock,
                "invalid frequency");


In my code, I am okay with frequency not being an exact multiple of the clock because it is based on external measurement of signals and I am fine with it rounding down on the pre scalar calculation (which I do).

I'm not sure what else that frequency value is used for, In 2.6.6 this same code has worked flawlessly in the field, but I'm always trying to be safe on what I am doing.

For now I have commented out the above code.


Return to “STM32 Support”

Who is online

Users browsing this forum: No registered users and 2 guests