Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
EbMonitor stopped working
#1
Sad 
I can do single stepping and all other debugging commands in my F407 project.  I have enabled the EbMonitor in tools and linker settings like in all other projects where EbMonitor is working.

Could the problem be in the loader file?  In past, I did use loader files provided by EmBitz.  Now, I am generating all source files and loader file with CubeMX.  I can see that the old project map files have the _read and _write symbols.  In the new project map file, there are no duplicate definitions for these.  Actually, there are no _read and _write symbols.

How can I fix this?
Cheers, Ollie
Reply
#2
Hi Ollie,
I work with EBMonitor on a STM32l476 project generated by CubeMx.
May be this is not your problem, but I have to add this to my main code:

#define EBmonitorBufLength ((uint16_t)0x200)
char EBmonitorBuffer[EBmonitorBufLength];
...
EBmonitor_buffer(stdout, EBmonitorBuffer, EBmonitorBufLength);

Cheers, Dario.
Reply
#3
(15-12-2017, 05:49 PM)hull Wrote: Hi Ollie,
I work with EBMonitor on a STM32l476 project generated by CubeMx.
May be this is not your problem, but I have to add this to my main code:

#define EBmonitorBufLength ((uint16_t)0x200)
char EBmonitorBuffer[EBmonitorBufLength];
...
EBmonitor_buffer(stdout, EBmonitorBuffer, EBmonitorBufLength);

Cheers, Dario.
Thanks Dario,

This did solve my problem.  Some questions:
1) Why is this required now with CubeMx when it has worked in past without it?
2) How can you prevent the memory allocation for release target?
3) How can the warning message be avoided
    "Src\main.c|109|warning: implicit declaration of function 'EBmonitor_buffer' [-Wimplicit-function-declaration]|"

Best Regards, Ollie
Reply
#4
Yes, I have the same questions. Any news on this?
Reply
#5
(17-12-2017, 07:21 AM)EmBitz Wrote: Yes, I have the same questions. Any news on this?
I don't have answers to the first two questions.  The 3rd question is about the normal forward referencing without a header file.  Here are the 3 sections of my CubeMx code
 
Code:
/* USER CODE BEGIN PV */
/* Private variables ---------------------------------------------------------*/
#define EBmonitorBufLength 128
char EBmonitorBuffer[EBmonitorBufLength];
:
/* USER CODE BEGIN PFP */
/* Private function prototypes -----------------------------------------------*/
void EBmonitor_buffer(FILE* , char*, uint16_t);
:
  /* USER CODE BEGIN 2 */
  EBmonitor_buffer(stdout, EBmonitorBuffer, EBmonitorBufLength);
Cheers, Ollie
Reply
#6
I really like EbMonitor and have been using it in most of my projects.  Now I have started to use FreeRTOS and there is a new problem.  These are the observations:

Outside the tasks, the EbMonitor works properly.  Inside all the tasks, EbMonitor doesn't work.  In other words, the printf function doesn't show text in the EbMonitor pane.

All hints are welcome.
Cheers, Ollie
Reply
#7
EbMonitor should not work in all tasks at the same time. Because the print function is tied to physics, and can not serve multiple requests at the same time - without delineating access to it.
  OliviliK - you can use my functions as a prototype. You need to replace the lines:
sSystem_task.system_us - real system time in mil seconds,
sTask_skip () is the "give way to CPU time" function, or forced task switching without waiting for the timeout to complete.
https://bitbucket.org/AVI-crak/rtos-cort...ew-default
Reply
#8
Thanks AVI,

I am not aware of the technology used in EbMonitor. My expectation was that all tasks are sharing the same infrastructure and that the sharing of that common resource was done at application level. It makes sense, that a simple implementation is expecting a completion of a read or write request before starting a new one.

Thanks for the link to RtoS. I will evaluate my alternatives to solve or avoid this problem.

Just curious, how many helicopters and cats you have received. =)
Cheers, Ollie
Reply
#9
(17-12-2017, 07:21 AM)EmBitz Wrote: Yes, I have the same questions. Any news on this?

Blush

Sorry, it was a failure in my code.  The EbMonitor works totally right inside and outside of FreeRTOS tasks.  Obviously, the application developer has to be familiar with the "parallel" operations in RTOS environment.
Cheers, Ollie
Reply
#10
The saga continues. Now, I am in a situation, where printf statements in a task cause a latent crash in the FreeRTOS scheduler. There are several different ways the FreeRTOS is crashing. When commenting out the printf statements everything works OK.

I have changed the EbMonitor buffer size in a range from 128 to 8192, but that has not correlated with the problem. I think that the mechanism is through a memory collision that comes evident in the FreeRTOS tick timer. It could be solved by changing the stack size or the heap size.

There have been no similar EbMonitor issues without FreeRTOS. In this case, the target platform is STM32F407VE using CubeMX HAL library.
Cheers, Ollie
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)