[Avrora] Avrora and Msp430/TelosB

[Urs Hunkeler]

Hi Ben,

Thanks for your support. I do assume that errors can be anywhere in the 
code, but so far most of the bugs were in the code I wrote myself. The 
issues that I found in the code present on sourceforge were mostly the 
memory layout (part of the memory of the Msp430 is mirrored), the status 
register (SR) not being implemented, and a lack of 16-bit memory access 
(16-bit IO-registers need to be written in one access, otherwise there 
is a problem with the side-effects). I didn't really look into it, but I 
have the impression that the interpreter currently assumes that all 
instructions take one cycle. That's the case for the Atmel MCUs, but not 
for the Msp430. That shouldn't cause my problems, though.

I guess that somewhere the program doesn't branch as it should. Possible 
reasons are a problem with my timer implementation (likely), or that one 
of the arithmetic flags doesn't get set properly (possible). The real 
problem is that I don't know where the things go wrong, and thus it is 
difficult to pin-point the problem. I just know that something doesn't 
work, and it probably happens after the initialization but before the 
microcontroller enters a low-power mode.

Debugging approaches that I used so far:
- Printing details on all write accesses to IO registers (that's how I 
know which internal devices needed implementation, and which parts of 
the devices need to be implemented first)
- Printing details on interrupts
- Printing details on low-power mode management
- For interesting situations (e.g., a special value is written to a 
register) I also print things like the PC (to see where in the assembly 
code the instruction is executed, and in what context)
- I now added code that checks every new PC value and looks at the code 
representation to see whether a function name is associated with the 
given address (nice implementation of the disassembler, thanks), and if 
so, print it. This gives me a good idea of the program flow.

Cheers,
Urs

On 01/13/2011 11:27 PM, Ben L. Titzer wrote:
> Impressive progress. I am not too sure how correct the MSP430
> interpreter is. Have you done some work to debug it, because I left it
> in a rather incomplete state before getting frustrated and starting work
> on something else.
>
> -B
>
> On Thu, Jan 13, 2011 at 8:50 AM, Urs Hunkeler <urs.hunkeler at epfl.ch
> <mailto:urs.hunkeler at epfl.ch>> wrote:
>
>     I've implemented a first version of everything that should be needed
>     to run the TinyOS Blink application on the TelosB simulation in
>     Avrora. It doesn't quite work and I am running out of ideas on how
>     to debug this. Does anybody have some more ideas? (problem
>     description follows)
>
>     What is implemented (at least to some extend):
>     - low-power modes (including energy monitoring)
>     - interrupts (simulated mcu wakes up on timer interrupts)
>     - timer A and B (including the compare mode of the capture & compare
>     registers, but not the capture mode)
>     - basic clock module (including dynamically changing clock source
>     (HF/LF) and prescaler for the ACLK and SMCLK signals)
>     - watchdog module (does not do resets but would signal if an error
>     occurs)
>     - digital input/output ports (LEDs are connected and seem to work)
>
>     What happens when I run the Blink application: With the debugging
>     statements that I have added, I can see that the Blink application
>     initializes. It runs the DCO calibration routine (although there is
>     nothing it can calibrate :-) ). It then initializes the ports (and
>     seems to try to initialize the external flash). After that it enters
>     the sleep mode (LPM3). TimerB is configured to run on the external
>     low-frequency clock. Interrupts for TimerB (TBIE) are enabled (so
>     the overflow will be signaled), but not for the capture/compare 0
>     (CCA0) module. With the configuration the TimerB gets, it overflows
>     every 2 simulated seconds and generates an interrupt. The program
>     seems to handle this interrupt and reenters sleep mode. It does not
>     appear to execute any pending tasks (that should occur much earlier
>     anyway).
>
>     If I force the TimerB CCA0 interrupt to constantly be enabled, the
>     program wakes up from sleep mode much earlier (about on time) and
>     turns on the red LED. It then reconfigures the TimerB CCA0 and
>     enables its interrupt, then enters sleep mode again. From now on the
>     TimerB CCA0 interrupt (TBCCR0 CCIFG) is regularly called (and
>     reconfigured with the TBCCR0 interrupt enabled), but the output for
>     the LEDs doesn't change anymore.
>
>     Any ideas on what could go wrong or how I could further debug the
>     program are welcome.
>
>     Cheers,
>     Urs
>
>     _______________________________________________
>     Avrora mailing list
>     Avrora at lists.ucla.edu <mailto:Avrora at lists.ucla.edu>
>     http://lists.ucla.edu/cgi-bin/mailman/listinfo/avrora
>
>
>
>
> _______________________________________________
> Avrora mailing list
> Avrora at lists.ucla.edu
> http://lists.ucla.edu/cgi-bin/mailman/listinfo/avrora