Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

missing logs #472

Closed
ali-rostami opened this issue Jun 11, 2024 · 6 comments
Closed

missing logs #472

ali-rostami opened this issue Jun 11, 2024 · 6 comments
Labels
question Further information is requested

Comments

@ali-rostami
Copy link
Contributor

Hi Thomas, I hope you are well.🙂
Thank you so much for your effort in this useful library.🙏

I want to print this:
trice(" dsm-1 [0] %u: tracing_mark_write: B|1|task_transmit_status\n", DWT->CYCCNT);
every 0.5 second in a log file.
this is the command I use:
trice l -p JLINK -args="-Device STM32G491RE -if SWD -Speed 50000 -RTTChannel 0" -pf none -ts ms -d16 -lf ./auto -hs off -color none -prefix none -liFmt off
I also attached my triceConfig:
triceConfig.zip
My OS is Win 11.

1- I increased the segger's BUFFER_SIZE_UP to 4096. I Commented CPU sleep lines in my firmware.
But still get this error:
CYCLE: 216 not equal expected value 215 - adjusting. Now 6 CycleEvents
I have no idea what else I should do. Would you please help me with what I'm doing wrong?

2- As you can see, I tried to prevent Trice from adding extra stuff (color, time...) to the lines but couldn't find a solution to remove the spaces at the beginning of the lines. In other words, it's like this:
dsm-1 [0] 100003084: tracing_mark_write: B|1|task_transmit_status
while I want it to be like this:
dsm-1 [0] 100003084: tracing_mark_write: B|1|task_transmit_status
So how can I do it?

@rokath
Copy link
Owner

rokath commented Jun 11, 2024

Not sure, if your -Speed value 50000 is too high, Ali. I use 4000 for that.

Your triceConfig.h and CLI switches match well. Please check the BUFFER_SIZE_UP value in your SEGGER_RTT_Conf.h file. I guess you did not touch it and 1024 is a good value to start with.

You could add the -s and/or the -debug switch to the trice line to see the incoming bytes and/or packages. That allows to check for missing/wrong bytes.

Also it could be interesting to to use the -v switch. This lets you see the name of the binary logfile. That file you can feed into the Trice tool and let it convert to strings to check if the error persists. For example:
trice log -v -p FILEBUFFER -args ./temp/trice-567289440.bin -pf none -d16.
If the error persists, there is probably some transmission issue. If not, it could be a Trice tool problem. You could also check the PC task manager, if there is enough computing power.

What you also can do: Use TriceWriteDeviceRtt0 instead of SEGGER_Write_RTT0_NoCheck32 just for investigation. The function SEGGER_Write_RTT0_NoCheck32 I wrote and TriceWriteDeviceRtt0 uses the SEGGER code. Because sometimes there are updates from SEGGER, the function SEGGER_Write_RTT0_NoCheck32 could get outdated.

One more idea: Add your own cycle counter to the payload just to see what happens. That increases your Trices from 8 to 12 bytes.

This could help you with the indent problem:

 -newlineIndent int
        Force newline offset for trice format strings with line breaks before end. -1=auto sense (default -1)

Good luck!

EDIT:

What exactly is your J-Link hardware? I am not 100% sure if all on-board J-Link adapters work perfect. Especially, when using them for long heavy load tests, it could happen, their inner buffers got "confused", so that I had to do a power cycle, to reset also the on-board J-Link adapter.

What you could also test: Generate Trices every 100ms instead of 500ms. Maybe there is a hidden timeout.

@ali-rostami
Copy link
Contributor Author

ali-rostami commented Jun 13, 2024

Thank you so much.
I'm using Jlink PRO. I tested the things you mentioned.
I think (hope not to see it again) the problem was for being in debug mode in VS Code in parallel running this comand:
trice l -p JLINK -args="-Device STM32G491RE -if SWD -Speed 50000 -RTTChannel 0" -pf none -ts ms -d16 -lf ./auto -hs off -color none -prefix none -liFmt off
Now after programming the microcontroller inside VS Code, I stop the debugging. Then I use the above command in git bash and it works properly.

Can I add something to the above command to restart the microcontroller?
I need to print the stuff from the beginning. The only workaround I found for this was to open jlink.exe separately, keep the microcontroller in reset mode, and then enter the above command in git bash. Which doesn't seem like a nice solution.

I also use -newlineIndent like this:
trice l -p JLINK -args="-Device STM32G491RE -if SWD -Speed 50000 -RTTChannel 0" -pf none -ts ms -d16 -lf ./auto -hs off -color none -prefix none -liFmt off -newlineIndent 0
But it didn't work. Did I use it correctly?

PS:
I used -Speed 50000 because in RTT viewer I saw it. I also check it in CLI by using SWOSpeed command. I set it to the max to be sure I won't miss anything.

Yeah, as I said BUFFER_SIZE_UP is 4096 in SEGGER_RTT_Conf.h file.

I also checked the PC task manager, everything seems fine.

What you also can do: Use TriceWriteDeviceRtt0 instead of SEGGER_Write_RTT0_NoCheck32 just for investigation. The function SEGGER_Write_RTT0_NoCheck32 I wrote and TriceWriteDeviceRtt0 uses the SEGGER code. Because sometimes there are updates from SEGGER, the function SEGGER_Write_RTT0_NoCheck32 could get outdated.

I made these changes in triceConfig.h
#define TRICE_SEGGER_RTT_32BIT_DIRECT_WRITE 0 #define TRICE_SEGGER_RTT_8BIT_DIRECT_WRITE 1
Not sure if it is what you meant, but if it is, the problem was still there.

@rokath
Copy link
Owner

rokath commented Jun 13, 2024

"I made these changes in triceConfig.h
#define TRICE_SEGGER_RTT_32BIT_DIRECT_WRITE 0 #define TRICE_SEGGER_RTT_8BIT_DIRECT_WRITE 1
Not sure if it is what you meant, but if it is, the problem was still there."

That tells us, that the 32-bit code is ok.

"I need to print the stuff from the beginning."

One possible way is shown here: https://github.com/rokath/trice/tree/master/examples#animation. If I understand it right, the RTT data stay in the RTT up-buffer until the J-Link probe is started to read them out. When using parallel output (RTT and serial) and connecting delayed, the serial data are gone but it is possible to see the RTT data from the beginning, as long the up-buffer is not overwritten.

"Can I add something to the above command to restart the microcontroller?"

The -args switch values are passed nearly 1:1 to the SEGGER tool. With -v you see details. Check the SEGGER documentation if there is a chance.

Concerning the -newlineIndent switch I opened #473.

@rokath
Copy link
Owner

rokath commented Jun 15, 2024

2- As you can see, I tried to prevent Trice from adding extra stuff (color, time...) to the lines but couldn't find a solution to remove the spaces at the beginning of the lines. In other words, it's like this:
dsm-1 [0] 100003084: tracing_mark_write: B|1|task_transmit_status
while I want it to be like this:
dsm-1 [0] 100003084: tracing_mark_write: B|1|task_transmit_status
So how can I do it?

SORRY for the wrong hint concerning -newlineIndent. This switch is useful when having several newlines \n inside a Trice message like trice( "line 1:A\nline 2:B\n\nline 3:C\n");

Please see this:

ms@LenovoP51Win11 MINGW64 /e/repos/trice/examples/vsCode_NucleoF030R8_instrumented (experimentalProtectOption)
$ trice l -p jlink -args "-Device STM32F030R8 -if SWD -Speed 4000 -RTTChannel 0" -pf NONE -d16
Jun 15 23:07:16.719642  jlink:                main.c    99
Jun 15 23:07:16.719642  jlink:
Jun 15 23:07:16.719642  jlink:                                                  ✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
Jun 15 23:07:16.719642  jlink:                                                  🎈🎈🎈🎈  𝕹𝖀𝕮𝕷𝕰𝕺-F030R8   🎈🎈🎈🎈
Jun 15 23:07:16.719642  jlink:                                                  🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃
Jun 15 23:07:16.719642  jlink:
Jun 15 23:07:16.719642  jlink:
Jun 15 23:07:16.720170  jlink:                main.c   101  842,150_450  Hello! 👋🙂
Jun 15 23:07:16.720170  jlink:                main.c   102  842,150_450  Hello! 👋🙂
Jun 15 23:07:16.720722  jlink:                main.c   103        5_654  Hello! 👋🙂
Jun 15 23:07:16.720839  jlink:                main.c   104        5_654  Hello! 👋🙂
Jun 15 23:07:16.720839  jlink:                main.c   105               Hello! 👋🙂
Jun 15 23:07:16.720839  jlink:                main.c   106               Hello! 👋🙂
     6 times: Warning w wrn warning W WRN WARNING Warn warn WARN
     7 times: Info i inf info informal I INF INFO INFORMAL
     7 times: Timestamp tim time TIM TIME TIMESTAMP timestamp
     7 times: Default DEFAULT default


ms@LenovoP51Win11 MINGW64 /e/repos/trice/examples/vsCode_NucleoF030R8_instrumented (experimentalProtectOption)
$ trice l -p jlink -args "-Device STM32F030R8 -if SWD -Speed 4000 -RTTChannel 0" -pf NONE -d16 -hs off -prefix off  -li off -ts off


                     ✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
                     🎈🎈🎈🎈  𝕹𝖀𝕮𝕷𝕰𝕺-F030R8   🎈🎈🎈🎈
                     🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃


  Hello! 👋🙂
  Hello! 👋🙂
  Hello! 👋🙂
  Hello! 👋🙂
  Hello! 👋🙂
  Hello! 👋🙂
     6 times: Warning w wrn warning W WRN WARNING Warn warn WARN
     7 times: Default DEFAULT default


ms@LenovoP51Win11 MINGW64 /e/repos/trice/examples/vsCode_NucleoF030R8_instrumented (experimentalProtectOption)
$ trice l -p jlink -args "-Device STM32F030R8 -if SWD -Speed 4000 -RTTChannel 0" -pf NONE -d16 -hs off -prefix off  -li off


                     ✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
                     🎈🎈🎈🎈  𝕹𝖀𝕮𝕷𝕰𝕺-F030R8   🎈🎈🎈🎈
                     🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃🍃


 842,150_450  Hello! 👋🙂
 842,150_450  Hello! 👋🙂
       5_654  Hello! 👋🙂
       5_654  Hello! 👋🙂
              Hello! 👋🙂
              Hello! 👋🙂
     6 times: Warning w wrn warning W WRN WARNING Warn warn WARN
     7 times: Timestamp tim time TIM TIME TIMESTAMP timestamp
     7 times: Default DEFAULT default


ms@LenovoP51Win11 MINGW64 /e/repos/trice/examples/vsCode_NucleoF030R8_instrumented (experimentalProtectOption)

Everything seems to work fine.

Could it be, your line
trice(" dsm-1 [0] %u: tracing_mark_write: B|1|task_transmit_status\n", DWT->CYCCNT);
contains tabs at the beginning? Maybe you change it into
trice("___dsm-1 [0] %u: tracing_mark_write: B|1|task_transmit_status\n", DWT->CYCCNT);
just for investigation?

@rokath
Copy link
Owner

rokath commented Jul 6, 2024

Can we close this?

@rokath rokath added the question Further information is requested label Jul 6, 2024
@ali-rostami
Copy link
Contributor Author

Hi Thomas, sorry for my late response. thank you so much🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants