topic Re: SS1 bean code is not able to be used in CodeWarrior for MCU

SS1 bean code is not able to be used

kji — Thu, 25 Jan 2007 23:44:39 GMT

Hello, I am using a 9S12E64 MCU as SPI Slave and another MCU (non-Freescale) as Master. The Master treat 9S12E MCU as an EEPROM (ST95040). I used SS bean with CW4.6 to generate SPI code (SS1 Module). There was any data to be received and sent. Attached is my code.

Questions:

SPICR1 was initialized as EC in main() when running step by step, SPICR1 = EC, SPISR = 20 (change to 00 late), and SPIDR = 00. when running fully SPICR1 = 04, SPISR = 20, and SPIDR = 00.
Are enable Interrupt (SPICR1=140) and disable Interrupt (SPICR1=12) needed in the Main() code?
Function SS1_SendChar(SS1_TComData Chr) be called at Main() but nothing happend with SPIDR.
Function SS1_RecvChar(SS1_TComData *Chr) be called at Main() but nothing happend with SPIDR.

Thanks for hlep.

SPI46.zip

Message Edited by t.dowe on 2009-10-22 09:55 AM

Re: SS1 bean code is not able to be used

bigmac — Fri, 26 Jan 2007 12:47:31 GMT

Hello,

Assuming you have no control over the master firmware, and a high SPI clock rate is generated by the master, it may not be feasible to "emulate" EEPROM with the MCU. The "EEPROM read" will be most problematic. I am assuming that the ST EEPROM operates similarly to other SPI serial EEPROMs.

Firstly, the slave firmware will probably need to use interrupts.

For a "read" command, the command byte would first be received by the slave, followed two address bytes. The MCU is then expected to return at least one byte to the master. However, the potential problem is that the slave MCU needs to read the final address byte, determine the return data associated with that address, and write the byte value to the SPI data register, all in less than one half SPI clock period. This is probably not feasible unless the SPI clock frequency is very low.

If this timing is not met, the first byte returned would contain "garbage", but the next byte returned would contain the written value.

My understanding is that SPI EEPROMs are usually compatible with SPI modes 0,0 or 1,1. I note that you have a setting of CPOL = 0 and CPHA = 1. You will need to retain CPHA = 1, since the /SS signal from the master will remain low for at least four byte periods (not compatible with CPHA = 0), so you may need to set CPOL = 1.

Regards,

Mac

Re: SS1 bean code is not able to be used

kji — Tue, 30 Jan 2007 00:48:54 GMT

Hello Mac,

Thank you for your reply. Here is the SPI initial codes (as a Slave) what CW4.6 generated. Both CPOL & CPHA are initialized as 1 ( SPICR1 = 204).

void SS1_Init(void)
{
/* SPICR1: SPIE=0,SPE=0,SPTIE=0,MSTR=0,CPOL=0,CPHA=1,SSOE=0,LSBFE=0 */
SPICR1 = 4;                          /* Reset the device register */
#pragma MESSAGE DISABLE C4002        /* Disable warning C4002 "Result not used" */
(void)SPISR;                         /* Read the status register */
(void)SPIDR;                         /* Read the data register */
/* SPICR2: ??=0,??=0,??=0,MODFEN=0,BIDIROE=0,??=0,SPISWAI=0,SPC0=0 */
SPICR2 = 0;                         /* Set control register 2 */
/* SPICR1: SPIE=1,SPE=1,SPTIE=0,MSTR=0,CPOL=1,CPHA=1,SSOE=0,LSBFE=0 */
SPICR1 = 204;                     /* Set control register 1 */
SerFlag = 0;                        /* Reset all flags */
ErrFlag = 0;                         /* Reset all flags in mirror */
SS1_EnEvent = TRUE;       /* Enable events */
EnUser = TRUE;                  /* Enable device */
SPIDR = SS1_EOF;            /* Store the empty char to the transmit register */
}

BTW, I don't know why CW3.1 generated control register SPICR1 = 12 with same bean setting as using CW4.6

Thanks again and BR,