We are trying to simulate the openMSP430 with icarus. The following problems occure:

• GPRs contain more and more invalid data (xxxx)
• After a timer interrupt, the program counter renders invalid (xxxx) after a few cycles.

We are using the fpga/xilinx_diligent/rtl as source for the simulation. We tried blockrams generated with Xilinx's coregen 13.3 and 10.1.

We are working on Linux (32Bit Linux Mint/64Bit ArchLinux).

The program we are testing in the simulation is a simple running LED light:

#include 
#include 

#define LED_DIR P3DIR
#define LED_OUT P3OUT


void initLEDs(void) {
  LED_DIR |= 0xff; //Set LED pins as outputs
  LED_OUT |= 0x01; //Turn on both LEDs
}

int shift_direction = 0x00;

int main(void) {

  WDTCTL = WDTPW + WDTHOLD; // Stop WDT
  initLEDs(); //Setup LEDs
  BCSCTL2 = 0x00;

  TACTL = TASSEL_1 | MC_1; //Set TimerA to use auxiliary clock in UP mode
  TACCTL0 = CCIE; //Enable the interrupt for TACCR0 match
  TACCR0 = 0x000A;
  WRITE_SR(GIE); //Enable global interrupts

  while(1) {}
}

interrupt(TIMERA0_VECTOR) TIMERA0_ISR(void) {
	if(shift_direction == 0x00)
	{  
		LED_OUT = LED_OUT > 1;
	}
	if(LED_OUT == 0x01)
		shift_direction = 0x00;
	else if (LED_OUT == 0x80)
		shift_direction = 0x01;
}

In the makefile, we defined msp430f135 as CPU.

Any help on simulating with icarus is appreciated. Thank you!

Hi Simeon,

Focusing on the "MOV &EDE, R5" instruction will probably give us the answer.
A first look on the IR[15:0] signal, shows us that EDE=0x120
This basically means that while reading the WDTCTL register (located at the address 0x120), you end up reading an X.

The first I would do is to double check the value of the "per_dout" input port of the openMSP430. If you see an X there, it means that one of your external peripherals is driving an X where it shouldn't.
After that, you can check the "per_dout" port of each of your peripherals to catch the guilty one :-)

Regards,
Olivier

Thank you for your tip

the problem was in openMSP430_fpga.v, about line 680:

//
// Combine peripheral data buses
//-------------------------------

assign per_dout = per_dout_dio  |
                  per_dout_tA;

instead of

//
// Combine peripheral data buses
//-------------------------------

assign per_dout = per_dout_dio  |
                  per_dout_tA   |
                  per_dout_7seg;

We don't use the module 7seg, and therefore the per_dout_7seg signal (and the per_dout signal) was set in the simulation to XX. Removing per_dout_7seg in this code line solved our issue. This also explains, why the code had no issues applied on the FPGA.

By the way, great project you realized there. We learned a lot from it ;)