1

I am trying to create a gatekeeper task to display the sensor data over the screen via UART. The attributes are defined in the structure as follows,

typedef struct Peripheral_data
{
    volatile char data[5];
    char Source[15];
    char String[5];
    char Nextline[3];
}PeriData;
/****************************************************************************************************************

 An array of structures can be declared and initilized according to the need.

 ****************************************************************************************************************/
static PeriData Peripheral[2] =
{
        { "", "TMPSEN", "Temp:", "\r\n"},

        { "", "Light_Sensor", "Lumos", "\r\n"}

};

But on sending via the queue the Source[0] of Peripheral[0] is changing to

\0

from

T

I am attaching screenshots for reference.

Screenshot 1: This picture shows the initilization of the structure at the beginning.enter image description here

Screenshot 2: This picture shows the data present in Source variable for the structure one. Here the data indexed by the 0 in the Source variable is T. But automatically, after sending via the queue, the Source[0] for the first structure becomes zero sir. But sometimes this happens before sending via queue aswell.enter image description here

Could someone suggest me what could be the problemhere. Moreover I developed this code, around one month back and it ran seamlessly over the same board. The chip am using is lpc 1768.

But when I tried to run the same code now, the above mentioned problem is arising.

vicky elango
  • 13
  • 2
  • Looks like a memory corruption which you will have to debug. I don't see how people on the Internet could help you with this. – Dmitry Grigoryev Apr 10 '17 at 09:33
  • Check if you made changes in the code somewhere; if it was working 1 month back, it should work now unless you made any changes in the hardware/software. – ammar.cma Apr 10 '17 at 09:43
  • @DmitryGrigoryev , I am relatively new to this field. Could you help me on how to sort this issue out. Currently, I am employing watchpoints to pinpoint the problem. Any other procedure would be much appreciated. – vicky elango Apr 10 '17 at 09:46
  • @ammar.cma Yes i know. Infact it was me who developed the code one month back. When I tried to run it now, I am encountering this issue. Moreover, the ADC's default setting is pullup configuration. Which means the adc pin must read 4096(12-bit adc). When I checked it last time i.e. one month back I observed 4096. But to my surprise, it throws someother value now. Could these two problem be because of hw issues? – vicky elango Apr 10 '17 at 09:51
  • @vicky If you have another hardware lying around; try flashing the firmware on another board and let us know the results. If they are the same, then your code has changed somewhere in between. – ammar.cma Apr 10 '17 at 09:56
  • @ammar.cma I resolved the problem by changing the array length of the variable `data` in the structure. It seems that the NULL character in the `data` variable is being overwritten on the first element in `Source` variable because structure elements are stored in contiguous memory location. Hence the problem. I increased the array size for `data` and now it works as expected. – vicky elango Apr 10 '17 at 10:05
  • That doesn't explain why it worked 1 month before; my speculation is that maybe the data being written was only 4 char long and NULL char was the 5th and hence, you didn't encounter any problem. – ammar.cma Apr 10 '17 at 10:11
  • @ammar.cma It seems somebody might have changed the array size while I was not around. Since, i am a student one of my friends might have made the change. Hence the confusion! – vicky elango Apr 10 '17 at 10:40

1 Answers1

3

Your 'data' char array is 5 characters length. However, it seems that you tried to store a full integer in it (65519 in 2nd screenshot). Once you include '\0' character for the end of string, you end up with 6 characters. This 6th character is probably the one written at the beginning of the 2nd field.

Edesign
  • 448
  • 4
  • 12