Saturday, August 19th 2017, 10:21pm UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.



Date of registration: Mar 1st 2017

Posts: 3


Thursday, March 2nd 2017, 9:57pm

Possible bugs

I am using 2.40e (and also tried 2.41a beta) with FreeRTOS under Linux (Centos 7) in load data from a .bin file mode.

My Event log shows:
xQueueGenericSend xQueue=0x00000000 ...

The description file has %I which from the documentation says should be replaced with a 'named resource' if available. I believe the bug is that since it is not available, it should be printing the resourceId in hex, but not 0.
I verified the data in the file contains a non-zero value.

If I highlight the xQueueGenericSend in the event list and press Shift-N to goto the next event of the same type, the program hangs and CPU usages goes to 100%. Occasionally it might work, but normally it hangs.

EDIT: Just tried 2.4.2 and same hang.

Also, it would be nice if the File -> Load (at least during the same session) remembered the last directory of the previously loaded file. Every time I load a new file, the file chooser resets back to the directory systemview was run from and I need to renavigate.

This post has been edited 1 times, last edit by "krbvroc1" (Mar 2nd 2017, 10:22pm)



Date of registration: Mar 1st 2017

Posts: 3


Friday, March 3rd 2017, 3:39am

Another bug:

traceQUEUE_SEND_FROM_ISR and traceQUEUE_SEND_FROM_ISR_FAILED use SEGGER_SYSVIEW_RecordU32x2, but the description format string expects 4 items:

96 xQueueGenericSendFromISR xQueue=%I pvItemToQueue=%p pxHigherPriorityTaskWoken=%u xCopyPosition=%u

EDIT: Also note that it appears all the macros in SEGGER_SYSVIEW_FreeRTOS.h that pass (U32)pxHigherPriorityTaskWoken are not really correct. It seems in all cases pxHigherPriorityTaskWoken is actually a pointer passed into the routine so it is not useful.I guess it should be deferenced.

This post has been edited 1 times, last edit by "krbvroc1" (Mar 3rd 2017, 3:59am)