[Avrora] Avrora and Msp430/TelosB

Mon Jan 17 09:45:50 PST 2011

Hi Zainul,

Thanks a lot for the tip! I didn't know about the test suit, but I think 
it's a great idea. I had a quick look and I don't quite understand the 
.tst file format. Is there some documentation about this?

By the way, I finally found the bug that was causing me all these 
problems. I added in-line assembly code to the TinyOS program that was 
accessing unused registers so that I could trace program execution from 
the simulator. It turned out that the implementation of the JGE 
instruction had a typo. I'll now go over the other instructions as well 
and will verify them.

Cheers,
Urs

On 1/15/11 4:17 AM, Zainul M Charbiwala wrote:
> 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
>>
> _______________________________________________
> Avrora mailing list
> Avrora at lists.ucla.edu
> http://lists.ucla.edu/cgi-bin/mailman/listinfo/avrora