SS1 bean code is not able to be used

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SS1 bean code is not able to be used

1,521 Views
kji
Contributor II
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:
  1. 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.
  2. Are enable Interrupt (SPICR1=140) and disable Interrupt (SPICR1=12) needed in the Main() code?
  3. Function SS1_SendChar(SS1_TComData Chr) be called at Main() but nothing happend with SPIDR.
  4. Function SS1_RecvChar(SS1_TComData *Chr) be called at Main() but nothing happend with SPIDR.

Thanks for hlep.

 
 
Message Edited by t.dowe on 2009-10-22 09:55 AM
Labels (1)
Tags (1)
0 Kudos
2 Replies

449 Views
bigmac
Specialist III
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
 

449 Views
kji
Contributor II
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,
KJ
0 Kudos