MID on MSP430F6659

Hello Hardy,

the MID peripheral is fully implemented. please see the MID section in the User Guide for its function and use. Sections 8.5 and 8.6 in particular describe how to use the MID.

MSP430F5xxx/6xxx User Guide;
www.ti.com/lit/slau208

Regards,
JH

Hi JH,

believe me, I've read those sections of the user manual several times. Did not help.
Actual problem is, that memory at 0x6c00 reads "0x3fff 0x3fff ...". So there is no MID entry table or whatsoever.

Is it possible that I switched off MID by incident? If yes, how to reenable?

Thanks Hardy


PS: info at 0x1a00 shows:
06 06 9A 34 2B 81 10 10 08 0A B8 A5 09 51 16 00 15 00 F8 FE 11 10 FA 7F FF FF 5C 08 B1 09 46 06 46 07 09 05 D7 05 12 06 16 80 58 80 CF 7F 02 7E 08 8A 0C 86 0E 2A 12 30 36 A8 38 AC 40 9A 8F 33 30 00 28 00 23 00 09 00 0F 00 05 00 FC 00 FA 10 41 02 30 02 39 01
3C 00 3D 00 44 00 40 01 48 02 42 02 43 01 A0 01 10 04 51 02 52 02 53 02 54 02 55 0A 5F 02 62 04 61 04 67 04 61 08 6A 02 6B 02 85 04 4A 0C 90 04 90 04 90 0C D0 08 C0 14 A8 04 98 10 B1 A8 64 65 40 90 91 D0 60 61 98 46 62 63 50 92 93 51 B0 68 C0 66 67 52 53 94
95 00 FF FF FF FF FF FF FF FF 20 01 00 A5 2E 01 00 11 10 01 E2 96 1C 01 00 26 10 01 1C 96 1C 01 9C B0 10 01 A0 96 12 01 22 14 14 01 9A F8 10 01 02 96 12 01 25 48 14 01 33 22 18 01 00 00 94 01 3B FF 58 01 00 5A 82 01 03 00 B6 1A C3 3C C3 3C 31 01 BF CA

JH,

you are trying to tell me, that I cannot dump (i.e. read) the memory at 0x6c00, while instruction fetch should work - right?

Where in slau208 is such behavior described? 1.11.1 says, that reads from vacant memory results in 0x3fff while fetching from such location will give either a "JMP $" or a PUC. Nowhere I can see the case "vacant for reading but valid for fetching"...

Stupid question comes to mind: how to assure that the MID actually exists? Is it somewhere in the TLV? Unfortunately the current MSPWare does not know about something like TLV_PID_MID. Reading memory from 0x6c00..0x6fff results in 0x3fff so it is not possible to check a magic MID word.

Hmm... reading 8.6 shows that there are two magic words: 0x2843 at _MidStart+0x00 and 0x80xy at _MidStart+0x02... how to access those values if reading returns 0x3fff!?

More questions:

• where is MdiInit() mentioned in slau208? (perhaps a typo...)
• what for is CSECKEY in the header file?
• how to disable BUS NMIs? BUSIFG is mentioned in the docs, but BUSIE not...
• what are the following TLV_PIDs (taken from TLV contained in 6659): 0x43, 0xd0, 0xfa?

In the end, I'm not absolutely sure, if the (or my) MSP430F6659 contains an MID. And I don't like this feeling of uncertainty. At least for my application.

Hardy

@OCY: feature check for existence of MID on the headers (if one could trust them!?) reveals the following:

$ grep -l _MidStart *
msp430f5358.h
msp430f5359.h
msp430f5658.h
msp430f5659.h
msp430f6458.h
msp430f6459.h
msp430f6658.h
msp430f6659.h

HardyGriech said:

Nevertheless let me state that I'm still a little bit irritated that I'm not able to dump the memory at location 0x6c00. So I have to do an API call into the fog and trust that it will _return_ with proper side effects. I think that the user manual should be updated to clarify this.

The following code was run in the MSP430F6659 to copy the MID ROM area to a copy in RAM:

#include <msp430.h>				

#define MID_ROM_SIZE_WORDS 512
int MID_rom_copy[MID_ROM_SIZE_WORDS];

int main(void) {
	const int *mid_rom = (int *) 0x6c00;
	int mid_index;
	WDTCTL = WDTPW | WDTHOLD;		// Stop watchdog timer

	for (mid_index = 0; mid_index < MID_ROM_SIZE_WORDS; mid_index++)
	{
	    MID_rom_copy[mid_index] = mid_rom[mid_index];
	}

	for(;;) {
	}
	
	return 0;
}

After this code was run, the MID_rom_copy RAM copy of the MID ROM could be inspected with the Disassembly or Memory Browser views and displayed non-0x3FFF values which look sensible. Therefore, the program running in the MSP430F6659 can read from the MID ROM.

Suspect there is a "feature" in the MSP430 emulator code / logic which is blocking read access to the MID ROM, will try and investigate.