LPC1343 Examples: SSP CR0 Inconsistency

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ktownsend on Thu Jan 14 09:31:57 MST 2010
There seems to be an inconsistency in the SSP demo code in the following line:

/* Set DSS data to 8-bit, Frame format SPI, CPOL = 0, CPHA = 0, and SCR is 15 */
LPC_SSP->CR0 = 0x0707;

The comment leads you to believe that SCR is 15, but 0X0707 corresponds to the SCR bits (15:8) being set to 0000 0111 (decimal 7). In any case, I don't seem to be able to get a correct clock signal supplying either 7 or 15 for the SCR bits.

Am I right in the following understanding for the SSP clock if the device is running at 72MHz and SCR is set to 7:

72000000 / (2 [CPSR] x (7 [SCR] + 1)) = 4.5MHz

I seem to be getting inconsistent/irregular clock signals, and have been trying to track down the problem. In any case, you might want to update the comment in any future revision to be less misleading.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by NXP_USA on Mon Jan 25 17:43:02 MST 2010

Quote: KTownsend
After digging into this a bit deeper, the example is indeed flawed (it seems it was just copy and pasted from the 32-bit examples). Providing a >16bit value seems to truncate the value and just takes the 16 lowest bits. For example, setting a 16-bit match register to 0x12345678 will still compile and not complain, but it actuallly causes the match register to be 0x5678, which could be a nasty bug if you're not expecting that (though to be fair it's an issue of bad SW as well). It might be worth updating this in the Keil package (timer16.h) just to be more clear, and to at least provide a 16-bit value with the define ... even if it should be obvious on closer inspection that the values won't work out. I'd at least change the method signature to U16 instead of the current U32 so that the compiler gives you a warning when you pass in an invalid value:

void init_timer16(uint8_t timer_num, uint32_t TimerInterval)
to
void init_timer16(uint8_t timer_num, uint16_t TimerInterval)

And the delay in mS function is essentially useless on a 16-bit timer, since with a 72MHz clock you can't even set a 1mS delay ...((72000000/1)/1000) = 72000 ... it's probably doing more harm than good, and I'd just remove it (it's already in the 32 bit examples) or change it to delay in 'ticks'.

Thanks for noticing this- the next revision of the Keil examples should be released to the NXP web in a week or so and have a fix for this which is to initialize the timer to count in uS (clock speed / 1000000) and set the 1mS delay #define to 1000.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ktownsend on Fri Jan 22 13:03:21 MST 2010
After digging into this a bit deeper, the example is indeed flawed (it seems it was just copy and pasted from the 32-bit examples). Providing a >16bit value seems to truncate the value and just takes the 16 lowest bits. For example, setting a 16-bit match register to 0x12345678 will still compile and not complain, but it actuallly causes the match register to be 0x5678, which could be a nasty bug if you're not expecting that (though to be fair it's an issue of bad SW as well). It might be worth updating this in the Keil package (timer16.h) just to be more clear, and to at least provide a 16-bit value with the define ... even if it should be obvious on closer inspection that the values won't work out. I'd at least change the method signature to U16 instead of the current U32 so that the compiler gives you a warning when you pass in an invalid value:

void init_timer16(uint8_t timer_num, uint32_t TimerInterval)
to
void init_timer16(uint8_t timer_num, uint16_t TimerInterval)

And the delay in mS function is essentially useless on a 16-bit timer, since with a 72MHz clock you can't even set a 1mS delay ...((72000000/1)/1000) = 72000 ... it's probably doing more harm than good, and I'd just remove it (it's already in the 32 bit examples) or change it to delay in 'ticks'.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ktownsend on Fri Jan 22 00:18:56 MST 2010
Not to nag, but I think that there's perhaps a problem with the 16-bit timer example as well? You give you the following definition and commentary in timer16.h (though I don't remember if this is in the Keil or the LPCXpress examples ... there are some differences between them):

#define TIME_INTERVAL ((SystemFrequency/LPC_SYSCON->SYSAHBCLKDIV)/100 - 1)
/* depending on the SystemFrequency and AHB clock divider setting,
if SystemFrequency = 60Mhz, SYSAHBCLKDIV = 4, SystemAHBFrequency = 1/4 SystemFrequency,
10mSec = 150.000-1 counts */

The calculations are all fine, but won't providing 150,000 to MR exceed the 16-bit maximum value?

[B]UPDATE[/B]: Sorry ... the misunderstanding seems to be my own. The match register seems to accept a 32-bit value, since when I compared the two 16-bit timers side by side, one with 65,535 as an interval and the other with 150K they seem to behave as expected, though this isn't the behaviour I'd expect on first glance (the UM states "[FONT=Arial][SIZE=2][FONT=Arial][SIZE=2]Four 16-bit match registers that allow ...[/SIZE][/FONT][/SIZE][/FONT]" on p.224).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by NXP_USA on Mon Jan 18 14:12:04 MST 2010

Quote: KTownsend
There seems to be an inconsistency in the SSP demo code in the following line:

/* Set DSS data to 8-bit, Frame format SPI, CPOL = 0, CPHA = 0, and SCR is 15 */
LPC_SSP->CR0 = 0x0707;

The comment leads you to believe that SCR is 15, but 0X0707 corresponds to the SCR bits (15:8) being set to 0000 0111 (decimal 7). In any case, I don't seem to be able to get a correct clock signal supplying either 7 or 15 for the SCR bits.

Am I right in the following understanding for the SSP clock if the device is running at 72MHz and SCR is set to 7:

72000000 / (2 [CPSR] x (7 [SCR] + 1)) = 4.5MHz

I seem to be getting inconsistent/irregular clock signals, and have been trying to track down the problem. In any case, you might want to update the comment in any future revision to be less misleading.

You are correct, the comment is in error. It has been fixed in the next example rev. I think the problem occurred when the default clock speed was changed in system_LPC13xx.c and the initialization in spi.c was corrected to match.

-NXP

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ktownsend on Fri Jan 15 04:56:16 MST 2010
The problem was a poorly specced cap ... but it's worth updating the comment on the SSP code in the next release. I think there's an update in the pipeline anyway due to the USB bug?