MSP430F5500 and the USB BSL

Ashleigh,
I will try to look into this and digest all of the things that you have already done. Your comment about USB9 and the regulators being turned off reminded me that the following errata is in work and may be applicable and wondering if increasing the decoupling capacitance on DVCC/AVCC would help.

If the device is powered via the 3.3V USB LDO the BSL invoke might not work once the USB cable is plugged in depending on the on board capacitance connected to DVCC/AVCC. The failure will be caused by the BSL code which is creating a voltage dip on the supply preventing successful code execution.

Workaround
1. Increasing the capacitance on DVCC/AVCC (typical 30 uF). However site effect on application needs to be considered.
Or
...

Regards,
Chris

Just for clarity I should add that the above experiments single stepping the BSL were done in the CCS debugger, allowing things like register change at any time.

On thinking about it some more, turning off the LDOs (USB9 errata) might not actually be an issue on a real product with the processor running at a fair speed - the caps on the VUSB (3v3) should hold up long enough for the next couple of instructions to execute which turns the LDOs back on.   So this *could* be a artifact of using the debugger.

Though that said, when I just set it to run, and then paused execution, it was sitting in an infinite loop in the NOP after the LDO's were disabled.

*Very strange*

My next plan had been to try and modify the BSL to remove that errata fix (USB 9); which is deletion of a couple of lines of code. And change the XT2 strength from its default 3 to 0 which suits the 4MHz resonator.... and then try again using the debugger.

The BSL seems to be a wrapper around a cut down of the MSP-Ware USB code, so in theory once that all gets running it should be much like the real application and enumerate properly.

Any other advice though it most gratefully received. 

I had 10 uF on that 3v3 line and removed it. Looks like I better find some more 10 uF caps and get soldering at least as a first attempt.

One more thing.

This development is co-operative between me (firmware) and another party (h/w, pcb load, etc). The other party loaded my initial firmware and at that time, it looks like they erase INFO_A, so the cal data for DCO, etc is all gone.

Is it possible that this is related to the troubles I see?

(I refer to SLAU208, section 1.9 Boot Code).

The F5xx family does not require anything in information memory; the calibration data is stored in the TLV device descriptors.

Is it possible that the rest of your circuit does funny things when the BSL does not configure all the pins?

Thanks, had not realised that the TLV descriptors were separate and not in Info memory. This is different to some of the other MSP430 family (which I know much better).

The external circuitry is *very* simple. There are 2 x outputs that go to a LED (which is driven in an active low mode, so when those port pins are pulled low the relevant LED illuminates. During BSL loading when those pins are inputs (and High Impedance) the LEDs are not lit (this is by observation).

There are also 3 x inputs that go to switches / separate piece of circuitry. The separate circuitry puts out either high / low. The switches are just pull ups to 3V3 and rely in normal operation on the internal pull down resistor. During BSL those inputs will be high impedance, no pull up or pull down. The switches will be either not connected (so the input is floating) or will be connected and the input is tied to 3V3.

The whole PCB is about 6 cm x 2 cm, 2 layer, plenty of ground fill.

So no, there are no special signals being applied.

Even in the case of input signals that might be floating, remember that the normal operating firmware starts and runs fine. The BSL is failing very early in its startup.

How is your firmware's initialization different? Has it smaller or larger delays at startup?

The real firmware is quite similar, though not identical in startup.

Unlike what I normally do (which is a complete ground up everything), I based the startup code on MSPWare on this product. So I rely on how that starts XT2, but it does pass the option to that to use the low (4-8 MHz) drive levels.

In other code I write for MSP430 I normally do a very careful processor initialise without use of any packages like MSPWare. I used it in this case because of the cross-dependence between the USB portion and other aspects (pin control, clocking, etc). There was not much to gain by eliminating it.

In the first instance, the major difference is that I don't try and start XT2 with a drive level to suit the higher frequency crystals / resonators. Much like my normal hand-grown code, I start with what suits the attached hardware. The BSL does not do this as it tries to discover the frequency of the attached crystal / resonator. [And this clever code is something I could remove from a custom BSL, too.]

The important thing to note here though is that the delays *should* not be relevant as the XT2 start never completes, it sits in the oscillator fault condition forever.

Even sorting that out in the debugger there still seem to be other issues. It does look a little like I'm just going to have to make a custom BSL and then sort each of the issues out one at a time.

Take care with modifying original TI BSL, to not blow JTAG fuse, that is located inside BSL flash memory space.

From my point of view, logging (UART on high rate or mailbox) is better than breakpoint debugging. I use this for development of my (assembler) USB stack, and CDC BSL with AES (under 2 KByte) on MSP430F550X. For development was used main flash, from where BSL was copied to RAM and executed from RAM (flash block write). When job was done, I just relocated code (with removed logs) from main flash to BSL flash area. 

For the benefit of a followup, here is what I have done which seems to work (so far).

Based on the latest BSL source, I have made a number of changes.

1. Removed some dead code from the cstartup (the linker was probably eliminating it anyhow).

2. Placed NOP after the DINT in cstartup (as suggested by IAR tools and as a good practice after a DINT in any case).

3. In BSL430_Low_Level_Init, removed more dead code (ACTION0 had code that does not actually do anything).  Also cleaned up a number of ambiguous comments.  And deleted all code that was commented out. [It was not used, and never going to be used as it won't fit it uncommented.]

-- The above are essentially a clean up --

4. In BSL430_USB_PI.c, removed all the code that tries to work out the system clock frequency, and just set the XT2 drive level to suit the attached 4 MHz resonator.  A consequence of this is that the calculation of the PLL setting for the USB module needs to be changed; therefore:

5. In usb.h, remove the declaration of wUSBPLL;   and in usb.c, also remove its declaration and change the assignment (in USB_enable()) to USBPLLDIVB = USBPLL_SETCLK_4_0.

After a rebuild (and quite a lot of messing about in IAR workbench), I have a compile that's clean, about 80-90 bytes smaller than the original, and this seems to work.

So the big question is:

When using a ceramic resonator on MSP430F5500 (rev D), why is it that setting the XT2 drive to default (ie 3) does not permit the oscillator to start properly?   It should just be a drive strength thing?  

And why on the MSP430F5529 that is on the development boards, does it work OK?

(For completeness, I have no changed delays or timing in the low level init portion or anywhere else).

------------------------

The next step is still in front of me:  the blank device when plugged in now enumerates on Windows 7, but loading the RAM BSL fails. Probably for all the same reasons, so my next task is to make the same changes for the RAM BSL. This should then see that stage working too. I hope to know in another few hours work.

Next step: How to rebuilt the RAM BSL...

My changes to cstart added a couple of NOPs, one after the DINT and one after the JMP $. These added 4 bytes to the size of cstart. Because "abromDeviceDescriptor" is explicitly placed @0x2516, this throws out the placement of the RAM BSL entry point.

Change needed here is in descriptors.c:

Change
#ifdef RAM_BASED_BSL
BYTE const abromDeviceDescriptor[SIZEOF_DEVICE_DESCRIPTOR] @ 0x2516 = {
#endif

To:
#ifdef RAM_BASED_BSL
BYTE const abromDeviceDescriptor[SIZEOF_DEVICE_DESCRIPTOR] @ 0x251A = {
#endif

This moves this initialised constant up a little to allow room for the modified ctsart to fit.

This constant could actually be placed almost anywhere so long as it is in RAM somewhere. A better method would be to use a pragma to place it into a named section and then just let the linker concatenate sections, giving non-sensitive automatic placement.

In order to build the RAM BSL, edit BSL_Device_File.h, and change:

#define RAM_WRITE_ONLY_BSL 0x80
//#define FULL_FLASH_BSL
//#define RAM_BASED_BSL 1

To:

//#define RAM_WRITE_ONLY_BSL 0x80
#define FULL_FLASH_BSL
#define RAM_BASED_BSL 1

After building, the resulting TXT file needs to be hand edited to remove the final placement of a (dodgy) reset vector. In my case, find these 2 lines at the end of the resulting TXT file and delete them both:

@FFFE
04 25

(You may be able to get away with leaving those as the ROM BSL only supports loading to RAM, it may just ignore that. But deleting is safer.)

I made a 2nd IAR EW project, based on the same source. This lets me pick the project I want, couple of quick source edits, and I can build either.

The source edits are not satisfactory (nor, really, is the final hand edit). So next up is to use some more changes to the source to allow building ROM and RAM BSLs using symbols defined in the IAR EW project files and no source changes at all. I'll leave that as an exercise for the reader.

None of this answers the question as to why XT2 is not starting with a 4.00 MHz resonator until the drive level is reduced.

But it does look like I now have a complete working solution. I have been able to enumerate the device from the ROM BSL, I can load application firmware over USB (RAM BSL goes in first), and using the PUR button when application firmware is in there, I can load an update.

So finally, its doing what it was supposed to do out of the box.

My factory load process will have to use Spy-Bi-Wire, and flash both the initial app + the ROM BSL, which is all possible.