Hi,
I am working on the 'Vybrid Strange Memory Overwrite' problem that was recently posted by Johannes Traxler (Thread 329003, see platform info there, DS-5 was updated to 5.19.0).
We have seen that it is not a stack overflow, but the whole application is affected as soon as we enable the external ADC (eADC) with
lwgpio_int_enable(&gpio_eadc1_drdy,TRUE);
ads131_send_cmd(g_spifd_0,CMD_START);
The execution gets then stuck in RTCS_create().
We have also seen debugger problems in connection with this (e.g. connection to target lost if we want to view the global variables).
I would be grateful for any help.
Best regards,
Heinz Roitner
Solved! Go to Solution.
Hello Heinz,
Have you compared your code to one of the provided examples for enabling an interrupt with GPIO? (eg, mqx/examples/gpio/gpio.c in MQX 4.0.2).
The Freescale MQX team may have more detailed input on this.
Thanks,
Timesys Support
Hi support,
I have now solved the particular problem with eADC. However, I have still the memory overwrite and want to set a watchpoint on a certain element of a data array.
Is there an easy way to do this (in documentation: 'Watchpoints are only supported on scalar values') ?
Thanks for your help.
Heinz
Hello Heinz,
According to this documentation, DS-5 watchpoints should be able to be set on a memory address:
ARM DS-5 Using the Debugger: About breakpoints and watchpoints
Are you able to set a watchpoint in the following fashion:
ARM DS-5 Using the Debugger: Setting a data watchpoint
Thanks,
Timesys Support
Hello support,
my question concerned the ability to set a watchpoint say on element a[5] of an array a[max_len]. This seems not possible. If max_len is small I can give the array elements individual names and set watchpoints on them. But this is impossible if max_len is large.
Anyhow, I am now updating MQX RTOS to 4.1.1 and I would very much hope things get better. I will let you know.
Regards, Heinz
Hello support,
changing to 4.1.1 did not change anything!
I am still desperate on the overwrite problem! I do see data overwrite all the time.
One observation: when I single-step from the program entry point, I get to _sched_start_internal(). In the next step it jumps to first line of main and the SP goes from 0x1F807EBC to 0x1F800EDC !!!
So it takes 28K of stack in this one step. Is this normal?
Also, why is the comment beside _sched_start_internal() /*WILL NEVER RETURN FROM HERE*/ ?
I appreciate your help!
Thanks, Heinz
Hello Heinz,
I believe it is likely that the scheduler function does not return, as it will wait for new tasks to be run. However, I am not familiar with the MQX scheduler internals, so Freescale will be able to better assist with this question, and typical stack usage for the scheduler.
Thanks,
Timesys Support
Hello Timesys Support,
I thought this is the Freescale community and I could reach Freescale experts here.
Could you tell me an address or tel.nr. where I should ask?
Thanks, Heinz
Hello Heinz,
We are providing support for Linux and MCC for the VF6xx processors, not MQX. karinavalencia, can the Freescale MQX team clarify the MQX questions that Heinz has?
Thanks,
Timesys Support
rendy can you help?
Sorry for late reply, I'll look on this.
Hi Rene,
my status is as follows: we have written a driver for the internal ADC of our Vybrid Arm-Cortex M4, where 8 channels are processed in 8 consecutive interrupts. If these interrupts are enabled, our DS-5 debugger (which otherwise works fine) shows all kinds of strange behavior (data overwrite, going into if blocks even when the condition is not satisfied, wrong calculations....). I could eliminate some problem(e.g. by different order of declaration of variables), but then another one pops up.
So something happens on a more fundamental level, maybe in MQX. But how could this be influenced by ADC interrupts?
Thanks, Heinz
Hi,
would it be possible to post here your code or a demo code which demonstrates your issue so I can replicate it?
Regarding your second question, why scheduler functions doesn't return: generally a scheduler is a loop which selects a task to be run, switches context to this task and it begins execution. Later the task finishes its executing (run out of its time slice, blocks or voluntarily gives up processor time). Execution context is then changed to scheduler, which repeats the loop.
Rene
Hi Rene,
I can tell you the following: we use 5 channels of ADC0 and 3 channels of ADC1 (because of pin multiplexing). All channels are configured properly, using the defines and typedefs from the file MVF50GS10MK50.h.
Then, for one channel after another, a software triggered conversion is enabled by
ADC0_BASE_PTR->HC1 = channel | (1 << ADC_HC1_AIEN1_SHIFT); (analog for ADC1 channels).
This prompts an ISR where the conversion value of the particular channel is read from the data register and stored into an array.
The ISR was registered in MQX by
intinstall_isr(NVIC_ADC0, iADC_ISR, 0); (analog for ADC1)
bspint_init(NVIC_ADC0, 3, 0, TRUE); (analog for ADC1)
So if I monitor the time spent in ISR with a scope, I see 8 consecutive pulses with pauses in between.
My question is: how can this procedure affect the debugger so badly?
Thanks, Heinz
Freundliche Gr??e / Best regards
i.A. Heinz Roitner
Forschung & Entwicklung
technosert electronic GmbH
Angererweg 7
4224 Wartberg/Aist
T: +43 (0)7236 20900-408
Heinz.Roitner@technosert.com<mailto:Heinz.Roitner@technosert.com>
www.technosert.com<http://www.technosert.com>;
Sitz: Wartberg ob der Aist, Handelsgericht Linz, FN 137503k
We are busy for your success!
It's really hard to say what's happening without a way to replicate the issue. Generally speaking the main reason for debugger to lose connection is when the chip is reset. I will try to write a sample program according your description, however it would be better and faster if you provide me your project.
What board do you use? Vybrid Tower?
Hi Rene,
we have decided now to put this problem on hold until later in the project.
So you don't need to test further. I will start a new thread when we take up the problem again.
Thanks, Heinz
Freundliche Gr??e / Best regards
i.A. Heinz Roitner
Forschung & Entwicklung
technosert electronic GmbH
Angererweg 7
4224 Wartberg/Aist
T: +43 (0)7236 20900-408
Heinz.Roitner@technosert.com<mailto:Heinz.Roitner@technosert.com>
www.technosert.com<http://www.technosert.com>;
Sitz: Wartberg ob der Aist, Handelsgericht Linz, FN 137503k
We are busy for your success!
Hi Rene,
please note that I have started a new thread
https://community.freescale.com/thread/331547
Thanks, Heinz
timesyssupport are you available to help with this case?