Hi,
I'm working on a project employing an XE164. In a ISR (CAN-RX-Interrupt) I want to fill a global variable with some values, then set a flag to signal the main program ok-to-read. The variable to fill is a structure, defined in the main program:
typedef struct {
unsigned char data[8];
unsigned char flags;
} t_data;
in main.c:
volatile t_data data;
The CAN-ISR is supposed to fill data[0..7] with the incoming bytes, then set flags to (e.g.) TRUE. The main program is supposed to look for the flag, handle the data, then reset the flag.
This works fine when I use a seperate variable. It does not always work, however, if "flags" is a member of a structure, like t_data.flags in the example above: It "mostly" works, but the main programm misses some new messages, about 10% of the time. Again, this does not occur if "flags" is a seperate variable.
Can anyone make sense of this? Could it be that read access by main to some other part of the structure also kills the ISR-write to the flags-part of the structure (or vv)?
Any help would be much apreciated.
Regs, Alto Speckhardt
* do you have additional interrupt sources? * maybe you have an alignment problem...? * ...
Other interrupt sources: There are other message objects active (RX and TX), but the MO in question is never reconfigured and has its own, dedicated data storages. The variables are accessed nowhere else, and the object remains untouched except by the ISR.
I don't quite understand what you mean by alignment?
processors load and store instructions assuming that the address is a multiple of the type you are loading or storing. If you load or store to an address that is not aligned to its type, then the behavior depends on the particular implementation. C compilers assume that a pointer is aligned unless you say otherwise. If a pointer isn’t aligned, then the program may give unexpected results. Can this apply to your program?
I see, thanks for the explanation.
No, I doubt that this could be the case. There is nothing I have explicitly positioned, the linker should have a free reign over where to put what. The default configuration of the compiler (Keil PK166 v6.11) should be fine by itself, shouldn't it? I've made no manual adjustments.
before somebody bites my head off - yes, I know, there are processors out there that do allow unaligned accesses...!
very well then. show us concise code excerpts!
Right. This was generated by DAVE, of course:
ISR:
void CAN_viSRN0(void) interrupt CAN_SRN0INT { [...] if(uwSRN0ObjHandler & MOSTAT_NEWDAT) // if NEWDAT is set { if (uwSRN0ObjHandler & MOSTAT_MSGLST) // if MSGLST is set { } else { // USER CODE BEGIN (SRN0_OBJ32,4) // transfer data: mydata.data[0] = CAN_HWOBJ[32].ubData[0]; // new struct content: mydata.rxstatus |= UPDATED; // USER CODE END }
main:
typedef struct { ubyte rxstatus; ubyte data[8]; } t_mydata; [...] volatile t_mydata mydata; [...] void can_rx() { // new data? if (mydata.rxstatus & UPDATED) { // handle data: [... read-access mydata.data[x] ...] // mark as handled: mydata.rxstatus &= ~UPDATED; } [...]
... and that's about it. The check "if rxstatus & UPDATED) misses out about 10% of the messages, sometimes more, sometimes less. The main applications is essentially doing loops, the check occurs about every 20ms.
If I extract t_mydata.rxstatus into a seperate variable, there is no problem.
"yes, I know, there are processors out there that do allow unaligned accesses...!"
8086, 80186, 80286, i386, i486, ... ;)
In this case, Intel designed logic into the bus controller to automatically take care of unaligned access.
For more modern x86 chips, it is normally way more important to not cross a cache-line boundary than to have unaligned access.
have you tried your program by the uv3 debugger? you can trigger a conditional breakpoint when your flag changes.
The problem is that I'd rather need a breakpoint triggered when the flag _doesn't_ change... ;-)
Ok, I will just do some more debugging and report back if I find a "smoking gun".
Meanwhile, thanks for your advice!
Do you have other code that touches other bits of this rxstatus variable?
Note that |= UPDATED will on most processors update all bits, since the processor has to do a read/modify/write.
If one part of the code do the read, while another part do a write, then you may loose changes to some bits.
No, I've also changed this to =TRUE and =FALSE, with the same results. The variable is only used between those two routines (ISR and one main routine). It was intended to signal different RX conditions (message lost etc.) but this hadn't been implemented yet.