[Avrora] Avrora and Msp430/TelosB

[Zainul M Charbiwala]

Hi Urs,

I remember that Ben had an extensive test suite for Avrora for the
ATMEGA. Do you think it is worthwhile replicating those tests for the
MSP430 just for sanity checks on all the different modules. The Blink
App, while simple, exercises many TOS internals and the result can get
convoluted pretty quickly.

Regards,
Zainul.



On Thu, Jan 13, 2011 at 11:08 PM, Urs Hunkeler <urs.hunkeler at epfl.ch> wrote:
> 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
>
> _______________________________________________
> Avrora mailing list
> Avrora at lists.ucla.edu
> http://lists.ucla.edu/cgi-bin/mailman/listinfo/avrora
>