This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Please see attached.....I have the first four bytes of a message get assigned ONE time at the front of main from either a default location or the permanent info location based on whether the permanent info location is empty (0xFF)....There have been times where I notice on the logic analyzer bus that the front four bytes are loaded from the default location even though the memory clearly shows values in the permanent info space....I have found that it will run with the correct (permanent info) data for a while then somehow get screwed up ....If I reset the issue goes away and all is good for some long period of time....Any ideas?
Last I saw, ,mssg[] was 8 bytes and permanent_Info[] was 9 bytes. If that's still the case, you're writing past the end of mssg[] and altering who-knows-what.
Not the case .....permanent info is now 5 bytes and only the first four get tacked into mssg....the rest of message is computed along the way....The assignment of the first four happens one time ...at the initialization of the code....that is it...
If sizeof(permanent_Info)==5, then 5 bytes are copied into mssg[]. How big is mssg[] now?
Also, what does pwmRemote() do?
Yes sizeof == 5.....The 5th character is just copied over from FRAM but I overwrite it down the road with data....mssg[8].....1st 4 bytes should be CONSISTENTLY loaded with either default or permanent_Info and for most of the time it is .....it's just every now and again it will get into a "something" and spit rf messages with the default even though permanent_Info exists.....a quick push of the reset cures it.....The only way this could be happening that I can see is code reboots and for whatever reason it see's FF in that space.....Possibly grabbing characters after [5]?
Here is my defn of permanent_Info
char permanent_Info[5] = {0xFF}; #pragma LOCATION (permanent_Info, 0x1810);
pwmRemote is nothing more than taking that 5th permanent_Info character and setting up a PWM for the correct LED....
will
WDTCTL = 0xDEAD;
clear all variables ?
I am noticing that I need to either push the reset button on my EVM or use a reset in CCS with the debugger to get the new number ID to load....I can see that the above command does a restart bcz I see an LED flash that I program to do so over the initialization....However it seems that my command memcpy does NOT load the new value with this WDTCTL pwd violation??? For instance it starts as 1234 (default)....I program a new ID 1615....I see an LED flash, I pause the code and I see 1615 in FRAM....I then send out a message that should start with the ID and it starts with 1234....I reset and then I send out a message and I get 1615 to start the message......
To follow on this if I flash a new number 2424, I can pause and see the number but until I reset I keep sending out messages that begin with 1615
Hi Steve
If you want to define an array at a define address you can also try this one (prefer to use even number for memory alignment)
#pragma PERSISTENT(flag)
char flag[6] = [];
**Attention** This is a public forum