Grace seems full of bugs

Samuel,

This is a know issue:

Bug 3044 - Ports 3 and 4 not initialized for FR59(5|4) and FR58(5|4) devices

It will be resolved in the next release of Grace, which will be in August.

If you are completely blocked, I can give you a file that will fix it.

Regards,

Joe

Thanks Joe,

Is there a list of other known bugs for my chip?  BTW, the link to bugzilla does not seem to work.

-- Sam

Sam,

These are the current known issues, all fixed in the upcoming Grace release:

Bug 3049 - CS_init.xdt and CS_A_init.xdt generating non-existent CS_SMCLKOff() DriverLib API call
Bug 3057 - Grace interface for GPIO has some pins with RE and IE swapped on FR594x_584x and FR595x_585x
Bug 3058 - CS_disableClockRequest always called in CS_init.c, even if clock requests are enabled

The Bugzilla repo must be TI internal. If you require more detail on these, let me know.

Regards,

Joe

Thanks Joe, Since I'm relatively new to this, and don't know all the ins and outs of the chip, I've been using Grace to make things easier, which is of course, the reason it was created. When it doesn't work, it ends up making things even harder because I'm not even sure where to look and Grace was keeping me from needing to learn all the ins and outs of the chip. My problem right now is that I need the SMCLK to output on pin 3.4 and Grace shows that as happening, but it isn't. Now I have to dig into the documentation to sort out what Grace should have done, and what it didn't do. I suspect that I have to designate the pinout manually in PinMux_init.c. Is there anything I need to do in the clock setup file, or did Grace do what it was supposed to there?

Sam,

Copy this PinMux.xs file into:

<CCS_Install_Dir>/<Grace_Install_Dir>/packages/ti/catalog/msp430/peripherals/pinmux

0044.PinMux.zip

It will take care of the PinMux_init.c.

Your clock init file should be OK, but you can post your .cfg script if you like and I'll take a look at it.

Regards,

Joe

Thanks! The patch worked, the clock is outputting on the pin. Now I can start debugging my code!

One last thing. Once I get this working, I'll be porting the code to a different MSP430 processor. Was the list of known issues you mentioned just for my chip or for all MSP430 chips?

Well. I thought things were good, but there is more bizarre behavior that is not making any sense to me. We've set up the A0 UART to be at 115Kbaud, but it seems to be sending out data at about 3 baud (yes, that is not a typo!) I've tried a couple of other baud rates, and it doesn't seem to have any effect on the speed of the output. Also, the bits sent out the UART don't quite match the bits that I'm putting in the TX buffer. Below is the EUSCI code generated by Grace (which from my novice view looks OK). Any clue what is happening?

Thanks.
Sam
-----------------------



void EUSCI_A0_graceInit(void)
{

/* USER CODE START (section: EUSCI_A0_graceInit_prologue) */
/* User initialization code */
/* USER CODE END (section: EUSCI_A0_graceInit_prologue) */

/* initialize UART for 115200 baud (based on a 1000000 Hz clock) */
if (STATUS_FAIL == EUSCI_A_UART_initAdvance(EUSCI_A0_BASE, EUSCI_A_UART_CLOCKSOURCE_SMCLK, 8, 0, 214,
EUSCI_A_UART_NO_PARITY, EUSCI_A_UART_LSB_FIRST, EUSCI_A_UART_ONE_STOP_BIT, EUSCI_A_UART_MODE, 0)) {
return;
}

/* enable eUSCI UART */
EUSCI_A_UART_enable(EUSCI_A0_BASE);

/* set deglitch time */
EUSCI_A_UART_selectDeglitchTime(EUSCI_A0_BASE, EUSCI_A_UART_DEGLITCH_TIME_200ns);

/* disable eUSCI UART transmit interrupt */
EUSCI_A_UART_disableInterrupt(EUSCI_A0_BASE, EUSCI_A_UART_TRANSMIT_INTERRUPT);

/* enable eUSCI UART receive interrupt */
EUSCI_A_UART_enableInterrupt(EUSCI_A0_BASE, EUSCI_A_UART_RECEIVE_INTERRUPT);

/* USER CODE START (section: EUSCI_A0_graceInit_epilogue) */
/* User code */
/* USER CODE END (section: EUSCI_A0_graceInit_epilogue) */

}

Sam,

Here's which processors the bugs apply to:

Bug 3049 - CS_init.xdt and CS_A_init.xdt generating non-existent CS_SMCLKOff() DriverLib API call
MSP430FR57xx, MSP430FR58xx, MSP430FR59xx

Bug 3057 - Grace interface for GPIO has some pins with RE and IE swapped on FR594x_584x and FR595x_585x
MSP430FR594x_584x, MSP430FR595x_585x

Bug 3058 - CS_disableClockRequest always called in CS_init.c, even if clock requests are enabled
MSP430FR58xx, MSP430FR59xx

Regards,
Joe

Sam,

Your initialization appears to be fine. Have you altered SMCLK any or is it default to 1 MHz? Please describe in detail the setup in which you are viewing the transmitted data. Are you able to provide a complete .c file that we can debug on our end?

Regards,
Ryan

We are outputing the SMCLK at 1MHz to pin 3.4.  MCLK is at 8 MHz.  SMCLK is dividing by 8.  We're using the 1 MHz signal elsewhere in our circuit.  To check that our circuit wasn't causing a problem, I disconnected the circuit from pin 3.4 and tried again.  The UART is still at 3 baud...

There is even more timing strangeness.  As an experiment, I changed the settings in grace so that MCLCK was at 16 MHz and SMCLK divided by 16 to get to 1 MHz.  Set like that the program would hang in the middle of the cs.c file during the initialization of the chip:

while((HWREG8(CS_BASE + OFS_CSCTL5) & LFXTOFFG) && --timeout)
{
//Clear OSC fault Flags fault flags
HWREG8(CS_BASE + OFS_CSCTL5) &= ~(LFXTOFFG);

// Clear the global fault flag. In case the LFXT caused the global fault
// flag to get set this will clear the global error condition. If any
// error condition persists, global flag will get again.
HWREG8(SFR_BASE + OFS_SFRIFG1) &= ~OFIFG;
}

This was called by the CS_A_init.c routine created by Grace, at this line:

* Start Low Frequency crystal in low frequency mode
*/
CS_LFXTStartWithTimeout(LFXTDRIVE_3, 100000);

I didn't change the settings of the LFXT!  Why would this be affected by the MCLK?

I'm going to create a very simple C program to see if I can get the UART to work, not using Grace.  I'll let you know what I find.  Thanks again for your assistance.

-- Sam

Sam,

Attached is a SMCLK-sourced USCI_A0 external loopback test at 115200 baud written in c, you should be able to easily modify it to test your setup:

5618.msp430fr59xx_euscia0_uart_03.c

Regards,

Ryan

Hi Ryan,

Thanks for the link.  With a little modification I was able to confirm that my hardware is working as expected.  However, this does not explain all the problems I've been having with Grace.  So now I have two options.  Slowly build on this code and incorporate all the code I've written into a stand-alone c program, or slowly build up a new Grace project using this routine.  Grace is easier to deal with (if it works) but ultimately, I'm not sure which will be less effort.  Any suggestions?

It seems quite ironic to me that Grace, a system that is meant to make it really easy to get projects made, has been the biggest hassle I've had to deal with so far...

-- Sam

Hey Sam,

Would it be possible for you to record the eUSCI_A register information as seen by the debugger for each instance (the Grace version and the C version)? I'm hoping to find a slight difference between the two that could explain why the Grace code is not working. This would give you a workaround to incorporate into your code while the Grace team investigates the issue.

Regards,
Ryan

I've gotten things to work with Grace again by taking my working program and merging it into a new Grace program. I still have no idea why I was having so much trouble before. I do notice that Grace sometimes gets into a "funk", and the only way out seems to be creating a new project and copying over the code.

BTW, I found a small bug in CSS. If you compile and try to debug a program that is missing a final bracket you sometimes won't get an error reported and then CSS tries to load a binary file that was never created and gets a file not found error. I was only able to track down the error in console and fix it. But it took quite a while until I figured out what was going on. Programming is difficult when your tools have bugs!

Yet another problem. Grace can't seem to remember my IO pin settings. I set pins to Output High, but the next time I look they are set back to Output Low. The IO module IS remember if they are Ins or Outs. This is easy to work around, but once again, I'm fearful of what Grace will do incorrectly next time...

Hi Ryan,
I've gotten around that problem for now (I'll let you know if it comes back!) but I have found two other bugs (see recent posts in this thread).

Sam,

Can you please explain this in more detail?

Which processor, peripheral and  pins? Screen shots of before and after would also be very helpful.

Regards,

Joe

Hi,

Once again Grace is in a funk.  This time it is the other UART (first problem was with USCI_A0, this time it is USCI_A1).  I copied code that worked with USCI_A0 to do pretty much the same thing with USCI_A1, but I could not get it to transmit at all.  I'd put a byte in the transmit buffer and it would just sit there.  So again,  I started a new project, copied the code into the new project and it works.  So something seems to happen with Grace that messes things up.  I looked at all the UCA1 registers and everything looks correct except that the buffer remains full so no empty buffer interrupt flag is ever set.  It is as if the USCI_A1 has been turned off and there is no way to turn it back on (I tried a reset cycle).  One thing I've noticed about these Grace "funks".  Both times this has happened has been after I have renamed my project.  So perhaps that is where the problem lies? 

I'm going to start a brand new project, and reconstruct all my grace settings and copy in the code.  Last time this worked, I hope it does again.

-- Sam

Hi Joe,

This version of PinMux.xs does not remember if outputs have internal pull-ups. If you set the output hi, when you come back later it will be reset to low.

-- Sam

So, after diving deeper into the depths of Grace (which is counter to the whole point of Grace),  I find that my problems all stemmed from this bug:

Bug 3058 - CS_disableClockRequest always called in CS_init.c, even if clock requests are enabled

I saw this in your previous e-mail, but didn't understand how it could have caused my problems.

The sample code that was sent to me for using the UART was not interrupt driven, so it worked but my code needs the ACLK to run the  UART in LPM3.  This bug keeps the the clock from being requested from the UART, so nothing happens.

So I hope others who encounter this problem will find this, because it wasted at least a week of my life!  To fix this bug stick enable commands into the user section of CS_A_init.c if you plan on using any peripherals in interrupt routines in low power modes.  Here's an example:

/* USER CODE START (section: CS_A_graceInit_epilogue) */
/* User code */

* SMCLK clock request enable. Setting this enables conditional module requests for ACLK
CS_enableClockRequest(CS_SMCLK);

/*
* ACLK clock request enable. Setting this enables conditional module requests for ACLK
*/
CS_enableClockRequest(CS_ACLK);
/* USER CODE END (section: CS_A_graceInit_epilogue) */

Hopefully this is the end of my hair-pulling frustration!  May I suggest that you don't release new versions of Grace unless they are bug free.  You will just frustrate your newbies.

-- Sam

Sorry, the SMCLK request comment was not commented out.