Reply by Bende Georg ●February 7, 20052005-02-07
Hello,

> Have you tried wrapping "interrupt-disable" and "restore interrupt level"
> around the at-risk code? (Just to prove that interrupts are breaking it.)

I'm not able to do this, since the affected bit fields are referred over 200 times in the software. I did it for the first variable that seemed to be buggy, the problem appeared at the next one, so I gave up this way of troubleshooting quickly.
The bitfield referencing on peripheral structures you have mentioned works for me reliable on both CW5.0 and CW7.0. (6.x versions were not tested.) The only thing that broke CW5.0 was when I tried to put these variables in a "while" cycle - in this case the compiled smashed the following error in my face:
Error : internal compiler error: File: 'IroNonRegLoopAccesses.c' Line:
559
main.c line 101 }

I'll try to isolate the problem more clearly, but right now it appears to be somewhat "mystic" for me. Sad that these DSPs don't support bit fields like microcontrollers do - the generated code is inefficient and slow.

Thanks,
Georg Bende > -----Ursprgliche Nachricht-----
> Von: Corey, Rick [mailto:]
> Gesendet: Montag, 7. Februar 2005 17:40
> An: Bende Georg;
> Betreff: RE: [motoroladsp] Using bitfields > Hi Georg
>
> Have you tried wrapping "interrupt-disable" and "restore
> interrupt level"
> around the at-risk code? (Just to prove that interrupts are
> breaking it.)
>
> A co-worker also used to use bitfields with CW 5 on DSP56F803
> (I think the
> CW version was 5.1.2). We used it to poke bitfields registers with
> more-easily-read C code. It was "pretty" code, though very
> inefficient.
>
> When we moved that same code to 56F8357s and CW 6.0, some of
> the bitfields
> broke - I forget whether it was Optimization Level 0 or 1.
>
> Writing to single-bit-bitfields seemed to be OK.
>
> One bitfield was 3bits wide, however, and the 21 lines of ASM
> generated for
> that assignment was strange - it set those 3bits wrong and
> altered other
> bits than just those 3. We probably had a pointer to a
> structure to access
> the register.
>
> I tore out the bitfield code, since it behaved differently
> from one rev of
> the compiler to the next.
>
> My experience was not like yours - mine worked wrong every
> time it ran, with
> the CW6 compiler and the 56F8357. It wasn't intermittent,
> and I had no
> reason to think it was Interrupt-related. It occurred at
> setup time when (I
> think) no interrupts should have been running (but I did not disable
> interrupts during the setup). I never used the CW6 compiler
> on the 56F803,
> or CW5 on the 56F8357.
>
> I'm going to wait before moving to CW 7 ... perhaps
> indefinitely. I don't
> want to be the one to discover new bugs. > I think this is a sample of the code that broke, but it was
> months ago:
>
> //Timer A0 Control Register bit wise structure
> union TMRACtrlReg0Union
> {
> volatile unsigned short *RegAddressVar;
>
> struct CtrlReg0Struct {
> unsigned OutPutMode : 3; /*LSb */
> unsigned CoInit : 1;
> unsigned CounterDir : 1;
> unsigned CountLengh : 1;
> unsigned CountOnce : 1;
> unsigned SecondaryCountSource : 2;
> unsigned PrimaryCountSource : 4;
> unsigned CountMode : 3; /*MSb */
> }*TMRACtrlReg0Struct;
>
> }TMRAcontrolReg0Int; > // GatedCount: enum, 011=3 turns TACH PULSE counter ON
> TMRAcontrolReg0Int.TMRACtrlReg0Struct->CountMode = GatedCount; >
> Rick Corey > -----Original Message-----
> From: Bende Georg [mailto:]
> Sent: Monday, February 07, 2005 10:32 AM
> To:
> Subject: [motoroladsp] Using bitfields >
> Hi CodeWarriors,
>
> I'm using bit fields very extensively in my software. Recently I had a
> very strange bug: the values of these bit fields were
> corrupted if there
> were a lot of interrupts in the same time in the system. It didn't
> happen at once - sometimes the system worked OK for 10 minutes,
> sometimes for an hour, but it came over the time for sure.
> The temporary
> workaround was that I converted the bitfields into 16-bit variables.
> It smells like some stack corruption caused by improper register
> pushing. The question is, why 16-bit variables make a
> difference? Where
> sould I look for the bug?
> I'm using compiler CW5.0 @ DSP56F803; the tests with CW7.0
> had the same
> result. The assembler dump seems to be correct.
> Any hints, suggestions or your own experiences on bitfields
> are welcome.
>
> BR,
> Georg Bende > ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> In low income neighborhoods, 84% do not own computers.
> At Network for Good, help bridge the Digital Divide!
> http://us.click.yahoo.com/EpW3eD/3MnJAA/cosFAA/PNArlB/TM
> --------------------------
> ------~- >