OpenCores
no use no use 1/1 no use no use
openMSP430 f1611
by simeon on Jul 10, 2012
simeon
Posts: 7
Joined: Oct 28, 2011
Last seen: Dec 7, 2017

I have problems to configure the openMSP430 to mimic the msp430f1611. It looks like the RAM is not properly accessed. I inserted a define to map periperal space of 4k:

`define PER_SIZE_4352_B
....
`ifdef PER_SIZE_4352_B
    `define PER_AWIDTH      12
    `define PER_SIZE      4352
`endif

The initializing routine makes Use of something like that:

.L__clear_bss_loop:
	WDTIMER_KICK
    4030:	92 42 04 11 	mov	&0x1104,&0x0120	

Which will reset the uC instantly because 0x0000 is copied from RAM.

I found out that the enable signal for the RAM element is not generated properly. It is somehow mixed between read/write enables of both ROM and RAM high and low. I digged down the wrong signals into the omsp_alu, where I got lost on the signal op_src_in_jmp (see screenshot). Now I think that I made something different wrong, as it looks too difficult. What am I missing here?

RE: openMSP430 f1611
by olivier.girard on Jul 10, 2012
olivier.girard
Posts: 21
Joined: Jan 9, 2009
Last seen: Aug 2, 2026
Hi Simeon,

the reason for this behavior is that the openMSP430 only supports a power of two for the peripheral address space size.
The valid configurations are only available by uncommenting the PER_SIZE_* defines in the advanced configuration section.

A simple fix is to simply edit the existing linker script of the msp430x1611 and adjust it to the oMSP configuration.

In any case, feel free to post it on the bugtracker ( http://opencores.org/project,openmsp430,bugtracker ) as an enhancement request. I will definitely fix this limitation as soon as I get the chance.

Olivier

RE: openMSP430 f1611
by olivier.girard on Jul 10, 2012
olivier.girard
Posts: 21
Joined: Jan 9, 2009
Last seen: Aug 2, 2026
Well, actually updating the Verilog to support any peripheral address space size is simple enough...

Basically if you open the "omsp_mem_backbone.v" file and go to line 182, you will just need to replace:
"...
wire dbg_per_en = dbg_mem_en & (dbg_mem_addr[15:`PER_AWIDTH+1]=={15-`PER_AWIDTH{1'b0}});
wire eu_per_en = eu_mb_en & (eu_mab[14:`PER_AWIDTH] =={15-`PER_AWIDTH{1'b0}});
..."

with

"...
wire dbg_per_en = dbg_mem_en & (dbg_mem_addr[15:1] < (`PER_SIZE >>1));
wire eu_per_en = eu_mb_en & (eu_mab < (`PER_SIZE>>1));
..."

Now, I won't update the official code just yet as this small and simple RTL change will have a lot of consequences on the verification environment...

Olivier
RE: openMSP430 f1611
by simeon on Jul 16, 2012
simeon
Posts: 7
Joined: Oct 28, 2011
Last seen: Dec 7, 2017
Hello Oliver,

thank you! It works now. I also submitted a request on the bugtracker: http://opencores.org/bug,view,2184

Well, to be exact: I'm just using the peripheral address space to map the RAM to 0x1100. A mirror of 2k RAM is available at 0x0200, but the f1611 has 10k of RAM which begin at 0x1100. Maybe it should be possible to map only the RAM to a specific location.
RE: openMSP430 f1611
by olivier.girard on Jul 24, 2012
olivier.girard
Posts: 21
Joined: Jan 9, 2009
Last seen: Aug 2, 2026
Hi Simeon,

I have updated the RTL so that you can now specify a custom size for the Program, Data and Peripheral address spaces.

However, if you really want to implement the same address map as the F1611, then I would recommend you to keep the peripheral address space to 512B (i.e. from 0x0000 to 0x0200 in the logical address space) and then create a Data memory space of 0x1100-0x0200+10kB=14080B (i.e. from 0x0200 to 0x3900 in the logical address space).

After that, you will just have to write a custom address decoder between the openMSP430 and the data memory in order to map:

- the first 2kB of RAM between 0x000 and 0x800 of the RAM physical address space (i.e. between 0x200 and 0xA00 of the oMSP logical address space).

- the full 10kB of RAM between 0xF00 and 0x3700 of the RAM physical address space (i.e. between 0x1100 and 0x3900 of the oMSP logical address space).

I hope this will solve your problem.

Cheers,
Olivier
no use no use 1/1 no use no use
© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.