SOLVED !!! Perplexing UART constant SSP_ERR_OVERFLOW issue

I am trying to read a simple sensor that puts out an ascii string 14 chars followed by cr and lf, then waits 1/2 second and repeats this string.  9600 baud, 8, n,n (basic serial)

My environment = S3A7 on my own PCB, IAR IDE, SSP 1.2.0.  Used Blinky with thread as base.  Selected HOCO 48 Mhz, HOCO as main clock.

My Project = Added Communications framework to blinky thread.  Set recv buffer to 100, set driver to channel 4, 9600 baud.  Enabled receive, disabled transmit.  Set recv and error interrupts to level 2.  Set ports/sci4 = pins A only, asynchronous UART.

Code:  I removed all code from the blinky thread and added the following code:

ssp_err_t module_err;
uint8_t buf[100];
uint32_t goodCount, overflowCount,otherCount;

void blinky_thread_entry(void)
{
module_err = g_sf_comms0.p_api->open(g_sf_comms0.p_ctrl, g_sf_comms0.p_cfg);

while (1)
{
module_err = g_sf_comms0.p_api->read(g_sf_comms0.p_ctrl, &buf[0], 1, TX_WAIT_FOREVER);
if(module_err == SSP_SUCCESS)
goodCount++;
else if(module_err == SSP_ERR_OVERFLOW)
overflowCount++;
else
otherCount++;
}
}

This is the entirety of my project and code.

When run:

  • I receive the first 15 characters OK (goodCount = 15)
  • Then every subsequent character causes and SSP_ERR_OVERFLOW (overflowCount keeps on climbing)
  • Tested this with live watch on the counts

Testing so far:

  • Debugged into low level uart code and set breakpoint for fix the hardware over run error.  It traps there and resets the SSR bit.
  • Fails with or without live watch running
  • VERY IMPORTANT: I wired in parallel a logic level to rs232 adaptor.  Tera term has absolutely no issues with the data.  There are never any bad characters or extra characters etc.  This is with or without Synergy running.
  • Therefore I do not think there is any hardware issues
  • Also verified with scope proper number of characters, good clean signals

This should be a cakewalk.  It is driving me crazy.  Any ideas would be appreciated.

Steve D

  • OK.  Per Warrens suggestion I enabled DTC.  All I had to do was enable the interrupt (level 2) in the DTC properties.

    Now it is working well.  I have received over 50,000 characters without throwing any errors from the framework.

    This begs the following questions:

    • Why can't the framework running at 48 Mhz keep up with 9600 baud when that is the only thing in the project?
    • Turning on DTC changed from IRQ upon character recv and stuffing that in to a circular buffer to direct transfer.  Why does that change make the system work?
    • Sounds like my clock is NOT running at 48 Mhz.  But then why did it catch characters then go into overflow in my original example?

    My system will have several more sensors using UART, I2C and RSPI frameworks to get their data.  It will also have a highspeed RS485 communications to the master controller.  I hope this poor little S3A7 at 48Mhz can keep up .....

    Any ideas would be appreciated.  THANKS !!!

    Steve D

  • In reply to Steve Dillier:

    I'm afraid I don't have much to offer, but as my current project makes heavy use of uarts I'm sure interested.

    Steve D. said he set his rx buffer at the configurator level to 100. I am guessing that is the "Read Input Queue Size". Does that mean his Comms Framework queue size is really 400 bytes? (The units for queue size are 4-bytes, right?)

    Steve D, you wrote that you "Set recv and error interrupts to level 2." At what levels are your non error rx and tx interrupts? If you set them to 0, do you have better success? Is there a downside to setting that to zero?

    Is there anything left over in the blinky stack that you might have missed?

    As a data point, I'm running an S7G2 system with my uart running at 230400 and so far I'm getting away with it. I haven't stressed the rx side yet, but tx has been doing well.

    Steve G.
  • In reply to Steve:

    Hello Steve G.

    I have done three projects on S7G2 with highspeed UARTS in each of them.  They were all on SSP 1.1.3 so I cannot speak to S7G2 on 1.2.0.

    I have only experienced one real problem on the UARTS with S7G2:

    • The system tick interrupt would go off and comsume the cpu for 20 to 50 ms at a time !!!  That really screwed up my highspeed communications
    • That said there was an easy fix.  The only problem is I can't remember exactly where it was.  It was related to NetX or USBX.  I had to include the threadX source and then in the threadX source properties "Disable" "Timer Process in ISR".  The downside was that system ticks were not accurate anymore - I did not care.  I set up my own quick timer at highest priority to get accurate control times

    Hope this helps you.

    By the way, I now have two UART sensors working on my project using the DTC enabled trick and they have worked for an hour or so and only accumulated 19 errors total and none of the errors caused problems.  Looks like I can make the little S3A7 do its job !!!

    Good luck with your project !!!

  • In reply to Steve Dillier:

    More results ... and more bad news ....

    • Per my post about the S3 carrying threadX.  I think that is not my problem
    • Per Karols information I went back to this post and changed the blinky thread to priority 7
    • I then removed the DTC from the UART driver
    • Back to failing after receiving  about 15 good bytes goes into overflow error and never comes back
    • My current thinking is that the problem is in the UART framework/driver
    • My code is still what is listed above - super simple
    • The thread should be suspending in the UART framework TX_WAIT_FOREVER waiting for a character irq in the UART --- of course I have no other threads so starvation should not be a problem

    I am stuck in my work now until I can figure out how to make the simple UARTs work at 9600 baud ....

    Any help would be appreciated.

    Steve D

  • In reply to Steve Dillier:

    Karol clearly knows his stuff. That said, my limited experience is without DTC my own project's uart under the com framework does not work.
  • In reply to Steve:

    Thanks Steve.

    My project will have a total of 4 UARTs running at the same time.  There is only one DTC controller.  Sounds like a nightmare to me.

    I have also tried just using the drivers and using the callback function to semaphore the thread to continue.  I get the same issue.  It receives some characters OK then goes into SSP_ERR_OVERFLOW every time a new character comes in.  The problem seems to be at the driver level.

    My project is DEAD until I figure this one out !!!

    Thanks for your help.

    I will keep updating this post as I get results.

    Steve D

  • In reply to Steve Dillier:

    Hi Steve,

    The DTC has slots in its vector table for every interrupt enabled in the system. So you can use DTC for all 4 UARTs if you choose.

    The overflow error means that characters are coming in when the receive FIFO is full before the receive interrupt is serviced. Did you try raising the SCI RXI interrupt priority to 0 to see if that helps?

    Also, could you check the value of SF_UART_COMMS_CFG_QUEUE_SIZE_WORDS in synergy_cfg/ssp_cfg/framework/sf_uart_comms_cfg.h? It should be at least 16 to avoid the overflow error you are seeing. The UART driver uses an internal FIFO, and can receive up to 16 bytes at once. If there aren't 16 slots in the receive queue at the framework layer and 16 bytes are received in succession, the framework layer will drop the extra bytes.

    Kristine
  • In reply to Kristine J.:

    Thank you Kristine.

    What about including threadX source and then in the threadX source properties "Disable" "Timer Process in ISR" ???

    This fixed some issues I had with threadX grabbing the cpu and not letting go for 20 to 50 ms at a time in a complicated S7 project.  If you think this might help please tell me the best way to include threadX source using SSP 1.2.0?

    For sure when threadX processes its ticks in ISR it owns the computer and all other irq's are blocked.  I proved this to my satisfaction in that other project.

    Your thoughts?

    Thanks,

    Steve D

  • In reply to Steve Dillier:

    Hello Kristine:

    My SF_UART_COMMS_CFG_QUEUE_SIZE_WORDS is set to 100.

    I had to change all irq's to priority 0 then my UART's work as planned.

    I then added I2C drivers (did not need framework).  At irq level 2 for the I2C drivers the I2C did not work.  Changed all irq's for I2C to level 0 and it is working fine now.

    Bottom line so far is that when I set all user selectable irq's to level 0 I now have two UART's and one I2C working well.

    Today I add an RSPI and finally two more UART's.  I will post my results.

    Thanks for your help !!!

    Steve D

  • Problem solved:

    • First post indicated my own PCB, S3A7, 48 Mhz
      • In the configurator clocks section I selected 48 Mhz for HOCO (hardware manual says this is OK)
      • Then I selected HOCO for the main clock
      • There were no reported errors
    • I was having all kinds of problems for a whole week - see all these posts and some others I posted last week.
    • Finally I set up GPT channel 4 to run periodic, 1000 raw counts, 50 percent duty cycle, output on P302 (happens to be a test point on my PCB)
      • Using my scope and calculator I determined that the cpu was running at less than 1 Mhz !!!!!!!!
      • I changed HOCO to 32Mhz and ran the test again
      • Scope and calculator determined CPU running at 32 Mhz !!!
    • Funny thing - now my communications etc are running so much better !!!

    Other than losing a weeks time and really bothering the Renesas FAE's I am back on track with my project.

    I am sure Renesas will fix this problem in one of the next releases.

    Thanks for every ones help !!!

    Steve

  • In reply to Steve Dillier:

    Hello Steve,

    Following your observations, I tracked the problem down to failure in call to the R_CGC_SystemClockSet. For frequencies greater than 32MHz, flash access requires at least 1 wait state - for some reason this is not being configured. We're investigating the root cause of the issue.

    Regards