The problem is that I "believe" to see sporadic errors with the DMA engine accessing on-chip xram. Sometimes the movx a,@dptr does not load the acc register. Silabs can't confirm such a bug, so I have to modify my rather complex firmware to nail the problem down. I'm still hoping that I'm an idiot and made a big programming mistake ;-)
If section 6.3 would not be true regarding on-chip xram access, we would always need to stop the dma engine for xram access. If it is true, we only need to do this on off-chip xram. Interrupts of course give the problem an additional dimension with the options: switch off irq during DMA0XBY check switch off irq during xram access getting accessing over the dma controller is not atomic, however it might be possible to check the timer that triggers the adc cycle if we keep the dma engine switched off for multiple movx instructions and check the DMA0DOE, in such a case we would also need to switch off irq otherwise it is not garanteed to switch dma engine on within a given time to prevent data lost. alternatively we could rise the dma engine above all other irqs (which would not be an option for my firmware, as the dma engine irq must have a very low priority) best regards Dani ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
