contiki-ng / mspsim Goto Github PK

Is not evaluated. The default mode is 3 -> Signal strength + data, but only the signal strength is evaluated (mode 1). This can have a significant impact with high CCA thesholds.
CCA_HYST is not evaluated, which however isn't that bad as long as there is no noise-model.

Hello guys! Today I was running a bunch of code with mspsim and I faced an unexpected behavior of the simulator. If you look carefully at the image, it can be seen that Register 7 (R7) is submitted to a byte swap operation (PC=0xFC66h), and there is nothing abnormal at this point. By analyzing two lines below (PC=0xFC6E) it can be seen that the same register is rolled right. If I'm not wrong, the expected value to be stored at Register 7 was 0x5200 but for some reason mspsim stored a null value at it. However, by analyzing the instruction bytes at the left, it can be seen that they actually refer to SXT R7 and not RRA.W R7. Considering that the instruction executed was SXT, the result is reasonable. I think it won't change at the end but I'd like to report this tiny possible issue. I'm using mspsim 0.97 at Ubuntu 13.10.

The new implementation of msp430_sync_dco from the following contiki-os/contiki commit:
contiki-os/contiki@68b65e6
works on z1 H/W nodes but not mspsim. Hardware timers (both A and B) go twice as slow as intended. For example, time_seconds() is equal to half the number of seconds elapsed since startup.

There is a timing difference between a real cc2420 and MSPSim: the time between a call to NETSTACK_RADIO.transmit() (with the radio OFF) and the end of the SFD is, on hardware, about 456 usec. In MSPSim it is 369 usec.

What is needed is to add an extra 87 usec delay in MSPSim before every transmission.

In 'Basic Clock Module+', RSELx is 03 bits of BCSCTL1. It's not equal to Basic Clock Module for MSP430x1xx that RSELx is 02 bits of BCSCTL1.

The se.sics.mspsim.core.BasicClockModule get RSELx value only for Basic Clock Module in write(). It causes wrong DCO configuration on Z1 mote simulation.

Hi

'make test' fails while complaining about unknown MCU. For compilation -mmcu=msp430x1611 is given, but this (generic) cpu type is not listed in msp430.h and leads to the warning.

make test
(cd tests && make)
make[1]: Entering directory `.../src/mspsim/tests'
msp430-gcc -I. -DWITH_ASCII -Wall -mmcu=msp430x1611 -g -Os -DAUTOSTART_ENABLE -c cputest.c -o cputest.co
In file included from cputest.c:44:0:
/usr/lib/gcc/msp430/4.6.3/../../../../msp430/include/msp430.h:813:2: warning: #warning Unable to identify and include MCU header, use -mmcu=MCU [-Wcpp]

using this software:
mspsim last version from git
gcc version 4.6.3 20120301 (mspgcc LTS 20120406 unpatched) (GCC)
Ubuntu 14.04 LTS

Some Components like Timer support only 16 Bit access for read and write. When Memory.AccessMode.BYTE is used the values of the odd addresses are incorrect.

In current(commit f2facc2) MSPSim,
NetworkConnection won't work properly.

I utilized an example program of Contiki-OS as follows;
Source code: /home/user/contiki/examples/ipv6/simple-udp-rpl/broadcast-example.c
And I created firmware for sky mote with following command,
make TARGET=sky broadcast-example

A mote executing this program sends 4 bytes of UDP message "Test"
to link-local allnodes multicast address with certain interval.
And, whenever the mote receives packets, it prints a message on USART1 Port Output.
I executed two MSPSims on a Instant Contiki 2.7 (Modified on 2013-11-15) which is running on VMware Fusion 6 Pro.
The command and option is as follows;
java -jar PATH_TO_MSPSIM/mspsim.jar PATH_TO_FIRMWARE/broadcast-example.sky -enableNetwork

In my understanding,
NetworkConnection encapsulates outgoing packets of CC2420 in TCP segments
and distributes the segments to other MSPSims through the loopback interface (e.g. lo).

I have captured packets on the loopback interface "lo" with Wireshark.
It shows that two MSPSims establishes TCP connection,
but no packet follows after this communication.

In addition,
I tried to distribute packets with using older MSPSims(commit 4b841fb).
Receiving packets are dropped in most cases
because RadioState of CC2420 is often being IDLE.
I guess this is not problem of NetworkConnection,
but motes with CC2420 rarely receives the distributed packets.

Please tell me if I use the wrong way.

Thanks.

CC2420 address recognition only works with Contiki-default way of sending data frames. Need to handle command frames and various addressing modes.

I was wondering what the status is of mspsim on sourceforge?

As the latest source code is only available on Github I would suggest making this clear on the sourceforge project page. This way, users don't spend unnecessary time on deprecated code.

if(counter<tccr)... in Timer.java is not working if counter is wrapped

A solution is to use the "bigcounter".
Calculate bigcounter
Subtraction tccr-bigCounter
Wrap the result with modulo Operation (the current timer wrap value)
=> get the correct div

Also the timer in Updown Mode results in problems.

I probably solve all in my fork.

Hello There! I recently strated using mspsim and I'm really struggling to get some of its functionalities. It is said that it "Supports loading of IHEX and ELF firmware files" but for some reason I didn't manage to find out how can I do it. What I'm really trying to do is to embed msp assembly code to the processor's core and watch to its behavior. I don't actually need any kind of peripheral devices nor RTOS for my purpose. Is my intent suitable to mspsim? How can I embed such an assembly code on the simulador?

I know that it's not the way it is done, but I'm currently trying to simply update memory locations during debug over one of those demo programs that come with the build. However, I'm not even able to make my mset requests get commited. Is there a way to load simple memory files instead of a whole funcional program?

Thank you very much!

Since there is no I2CUnit class, compiling TMP112.java failed.

how can i simulate an adxl345 using the accelerometer interface? i have to use I2CUnit?

Is there a documentation available (except the source code)?

I solved this by inserting

if (!interruptEnable) resetTIV(cycles);

after Line 691.

I am not that this is a acceptable solution

Hello guys! Today I was debugging a little software with MSPSIM and I really got stuck while trying to understand the effects of the status flags after subtraction operations with the simulator. I was performing a set of operations right in the registers (R4 and R14) and the two following operations were performed in a row:

SUB.B #0x0002, R14; R14 was loaded with 0x0000 -> Expected Status Flags: SR: -N--
SUB.B #0x0002, R4; R4 was loaded with 0x00FF -> Expected Status Flags: SR: -N-C

Results: R14 -> 0x00FE; R4 -> 0x00FD

The simulator successfully stores the correct results at the registers however, when performing these operations, I've noticed that it sets the Carry bit as a result of the first instruction which I believe may lead to unexpected behaviors. This is so, because a SUB instruction is performed by MSP430 CPU as a sum of the two's complement representation of the source, with the destination (and storing the result at the destination afterwards), like this: dst <- dst + [not(src) + 1]. Taking this into account, I believe that a carry (borrow) can't be generated as result of the first subtraction. I'll try to demonstrate below:

2'b                 ->   0 0 0 0   0 0 1 0 
One's Complement    ->   1 1 1 1   1 1 0 1 

                                       1 <-----Carry
Two's Complement    ->   1 1 1 1   1 1 0 1 
                       + 0 0 0 0   0 0 0 1 
                         -----------------
                         1 1 1 1   1 1 1 0 <-- 0x00FE

Subtraction         ->   0 0 0 0   0 0 0 0
                       + 1 1 1 1   1 1 1 0
                         -----------------
                         1 1 1 1   1 1 1 0 <-- 0x00FE (namely -2)

At the cluttered diagram I've shown above, neither the 'Two's complement' operation nor the sum itself generates a carry out and thus the status bit could not be set. I'm not sure if my assumptions are correct, so I'd really appreciate a little help to understand what's happening on these bit operations. Remember that I'm performing byte-wise operations and I've not yet tested the same code with word-size operands.
Thank you very much!

*PS: I don't know if this is the best place to ask such kind of question but I couldn't manage to find other place ;)