Posts by pbizzarri

Goodmorning
I also open a ticket.

Hi Alex, thanks for reply.
please take in account this thread: [SOLVED] SWO during Debugging Microcontroller Renesas RA6M5 (R7FA6M5BH) in Renesas demoboard doesn't work using Jlink Ultra+ and instead works with J-Link OB-S124 embedded in demoboard?

Using JLINK ULTRA+ in Renesas IDE-Debugger (eclipse based) instead of OZONE, everything works.
This is the reason due i think issue could be related to OZONE

Let's wait your collegues feedback

Hi, thanks for quick reply

Your explanation is very clear, and also help us in undertstanding better where OS timer SW are called ("Cortex-M embOS software timers are executed within the PendSV()")

Your workaround seems works fine in my tests.

I defined a macro like this:
// check OS SW timer context
#define OS_IS_SW_TIMER_CONTEXT() ((NULL != OS_TIMER_GetCurrent()) ? 1:0)

and now our code tests both conditions using (OS_InInterrupt() || OS_IS_SW_TIMER_CONTEXT() )

Let me suggest to add this macro or something similar also in EMBOS macros.

Hi Alex
Any updates from the log posted? do you think i have to create an issue ticket for this?
Thanks in advance

We are using OS version: V5.18.0.3

We have a function that uses mutex, and it is used inside tasks and in ISR function.
In order to avoid OS error, mutex usage is under condition, checking if caller is in task execution or in ISR exection, using API OS_InInterrupt()
See example code below

void doSomething(void)
{
   bool isISR = FALSE;
   // check if it is called inside ISR
   isISR = (OS_InInterrupt()) ? TRUE : FALSE;
   // thread safe access if caller is NOT an ISR
   if ( isISR == FALSE )
   {
      OS_Use(&some_mutex);
   }
   // do something code
   // thread safe access if caller is NOT an ISR
   if ( isISR == FALSE )
   {
      OS_Unuse(&some_mutex);
   }
}

This solution works fine and as expected from embos documentation for API OS_InInterrupt() in both scenarios

BUT, instead, if the same function is used as callback for a timer SW (where caller is OS code that is called in OS sysTick ISR), API OS_InInterrupt() return WRONG value (it returns "NO isr"),
so our code goes in OS_error function for invalid usage of OS API inside an ISR

I didn't see any other way for our code to understand if caller is task code or SW timer, so i think this is an API bug

Attached screenshot from debugging:
(1) timer with callback and mutex create
(2) debug inside function called by SW timer, where isISRtest from OS_InInterrupt() is showed with wrong value
(3) after this, mutex function is called and code goes in OS_error

Hi Alex
Thanks for reply

Attached full logs as you requested

Hi Alex.
You are right! I used J-Link Configurator to set max SWO speed to 1MHz, and with the same scenario i saw from jlink log that now TPIU_ACPR is set to 99 (so clock prescaler 100, so from 100MHz SWO pin clock is 1MHz) and now it works!!

So, my understanding was also corrects: some behaviours are up to JLINK devices and can be changed with settings from IDE, but renesas IDE sets few parameters.

Regarding the Ozone thread:
We like to debug with it, it is a very powerful tool, so i will wait for reply from your collegues, hopefully soon as possible

Thanks

Hi Alex, thanks for reply

As i said in my post, i cannot perform the same test using segger ozone due another issue (posted)
Instead i did my test using renesas e2studio (eclipse based) where i have limited config options for jlink debugger
I followed steps provided by renesas : https://en-support.renesas.com/knowledgeBase/20540919

I can only set core speed, as they explained (see below)
The only difference is jlink used: OB or Ultra+, and differences i saw in logs attached in previous post (i'm not able to understand what SWO speed is used in both cases, from the logs)

In my understanding, following your request, if i read jlink logs in both cases, as i said above:
if CPU bus speed for SWO is 100MHz inside the core (according to Renesas docs), settings for TPIU_ACPR register means 500KHz for SWO pin speed in case of OB, and around 67MHz in case of Ultra+, but i have no chance to change behaviour with debugger settings in e2studio IDE.
(Only in OZONE i have more control on SWO settings, but it causes microcontroller stuck)

Do you think i have to open a ticket for this?
Thanks in advance
[Blocked Image: https://en-support.renesas.com/api/attachments/image/784358/e3efa3ed-563a-4440-b10f-2fcd9e78e5ed.png]

I'm using a Renesas demobaord with RA6M5 (R7FA6M5BH) microcontroller and e2studio IDE-Debugger (eclipse based)
I configured debugging with jlink over SWD and enabled SWO for printf debug using ITM (SWO)

Debugging with an external Jlink Ultra+ (version 7.96H) i didn't see any print on console
Instead, using an oboard jlink (J-Link OB-S124 compiled Oct 30 2023) SWO works fine and i see print on console

Capturing jlink DLL log in both cases, when SWO is enabled in IDE, i saw a difference in registers programming sequence, writing TPIU_ACPR:
in case of on boad J-Link OB-S124, 0xC7 value is written and SWO works, instead in case of Jlink Ultra+, 0x02 value is written and SWO doesn't work

Attached log for both sequences.

Due nothing changed in IDE-Debug settings (in e2studio project) in both cases, i suppose that different behaviour is up to jlink devices, so it seems an issue on jlink Ultra+ firmware

I'm not able to perform a similar test using SEGGER OZONE due a critical issue in OZONE with enabling SWO using Renesas RA6M5
See this post:
https://forum.segger.com/index.php/Thre…33883#post33883

I'm trying to use printf over ITM channel (SWO) with microcontroller Renesas RA6M5 (R7FA6M5BH)
I'm using ozone (version 3.34) and my JLINK Ultra+ with JLINK updated to version 7.96H
Ozone project is well configured for SWD and SWO (see attached ozone project "R7FA6M5_2Mb.jdebug")

When i tried to enable SWO, during debug session (Right click on terminal console, "Capture SWO"), this operation causes debugger disconnection and microcontroller in stuck.
After this operation debug is not possible anymore, even with a microcontroller reset: only a power cycle will recovery

I captured JLINK DLL logger and i attached here ("LOGGER_OZONE.txt")
My understanding is something wrong was done in sequence over microcontroller registers for enabling SWO.

Let me add that instead i was able to use SWO inside Renesas e2studio, using a JLINK embedded on their demoboard (J-Link OB-S124 compiled Oct 30 2023 12:13:12)
I captured SWO enabling also in this scenario and I attached here ("jlinkOB_seqSWO.txt")
My understanding is that a difference sequence is performed by combination of e2studio and embedded jlink.