Hi u all!
I'm facing a problem here, I'm trying to develop a serial flash memory interface here. The memory is M25P128, and I'm using LPC2368.
The thing is..I don't have much experience with SPI/SSP. Well.. I've downloaded some examples but I couldn't establish the communication appropriately. Ideally I should have an oscilloscope to check all this, but..
The following code just try to request from the memory its status register:
int InitSSP() { PCONP = 1<<10; PINSEL0 = 0xA8000; PINMODE0 = 0xA8000;// Here is my first doubt, the pins should be configured with pull-up or not? //INTERRUPT VICVectAddr11 = (unsigned long) SSP_Isr; VICVectCntl11 = 0; VICIntEnable |= 0x800; // 11th bit is the SSP1 FIO2DIR1 = (1<<3); //SS Pin - configured as output SSP1CR1 = 0;//SSP disable SSP1CR0 = 0x07; SSP1CPSR= 10; SSP1IMSC = 3;//Receives int SSP1CR1 = 2; } void SSP_Isr(void) __irq { spiBuf[0] = SSP1DR; VICVectAddr = 0; // reset VIC FIO2PIN1 = 1<<3;//HIGH } int WriteFlash()//Adress, Data, size { FIO2PIN1 = 1<<3; //HIGH FIO2PIN1 = 0<<3; //LOW SSP1DR = 0x05; //Instrução WREN while (!(SSP1SR & SSPSR_BSY)); //FIO2PIN1 = 1<<3; //HIGH - In this test I set the High signal in the interruption method because it should be set after receive the message from the memory }
The problem is, doesn't matter which instruction I send I still receive answers that doesn't make any sense! And should be just a few specific instructions that the memory should answer back.
thanks
Ideally I should have an oscilloscope to check all this, but..
No, you must have an oscilloscope (or logic analyzer) to check this. Without one of those you have essentially no chance at all to find out what's going wrong.
I really wanted to have an osciloscpoe, but I'm not the boss.. I'm just a trainee..That's not up to me..
To make you life easier considering the circumstances, consider using CMSIS to address your device. That way you can largely exclude peripheral configuration issues.
Is CMSIS available for the LPC2368?
I think so.
Ho crap - of course not!
Talk to me boss - I'm doing too many different things, it has its toll :-)
I run another test and I continue to get an receive interrupt although I have the SS HIGH! And HIGH means NOT SELECTED!
The board has another components in the same port, but they're all not assembled.. There is possibly a HW problem..
If you are going to interface a memory, it's reasoanble to believe that you have configured your SSP as master.
When master, then it can perform SPI transfers without caring about state of SS (slave-select line). The slave must look at this pin for slave select. The master can use whatever GPIO pin to manually create slave select - how else would a master be able to select which of multiple slaves it should talk with?
Next is that SPI is two-way so if you send one word, you will also receive one word. So you can receive data with whatever state the SS pin has.
Thank you Per, I'm not familiar with the SPI communication. I thought that if the Slave were not selected I shouldn't get any response back..
And for the record I receive this "answer" for any byte I send, even if it's make no sense for the memory.
A doubt that occurs to me and I didn't find in the manual is how the controller knows when to "cut" the Clock signal? I understood that the clock signal starts when I put a word in the Data FIFO and it starts a transfer, but when it stops? If I'm receiving a continuous response from the memory the controller will automatically stop the clock when detect that the memory stopped to send data?
In my board I have an pull-up in the SS pin of the memory and a pull-down in the Clock pin of the memory as it says in the datasheet. But in the datasheet doesn't specify the value of this resistors, I put both 10k.. should I change to another one?
If the master doesn't drive a pin - whatever pin that is used - that is named SS on the slave (which is the memory chip) then the slave will not know that it should send data back.
But the master - when performing a transfer - will not care. It will still sample as many bits incomming as it is sending bits out. In a situation where no slave is enabled, pull-up or whatever will decide if the master will sample high or low bits. But it will sample bits on MISO (Master In Slave Out) pin at same speed as it sends out data on MOSI.
In the end - the master isn't in need of any slave-select signal. Only the slaves are. And a digital input don't have any special signal level that says "don't read me". It will make a low or high read - potentially with a lot of extra current consumption when the signal is floating.
Per you said that "It will still sample as many bits incomming as it is sending bits out."
But if I want to receive 64 data bits from the card? In the manual of the memory I should send the respective command and the memory will continuously send data until the SS were deselected (I understood that this signal has no effect for the master). Following you were saying, in this case that I want to receive 8 data bytes, I should send the respective memory command and put another 8 extra bytes in the Data Register to the controller identify that I want to receive 8 bytes? That's it?
To get 64 bits from the card to the processor, the card needs to see 64 clocks on the SPI clock line (while the card also sees the slave select signal active).
So how do you get 64 clock ticks on the clock signal? Exactly - by sending 64 bits of dummy data to the card. It is the master that owns the clock signal, and the master must transmit to be able to receive. And it will always receive when it is transmitting.
In this case, you should probably send 8 bytes of 0xff (if the idle state of the data lines are expected to be high) to generate a 64-bit dual-direction transfer. Dummy data to the memory chip and read data from chip to processor.
I'm not familiar with the SPI communication then get familiar with it. you already have one hand tied behind your back (your boss say "no scope") and unless you make yourself TOTALLY "familiar with the SPI communication" (which your boss can not stop you from) you will, under those circumstances never get to ways end.
Erik
PS find yourself another job, working with micros for a boss that will not buy a scope has no future.
SPI communication really is a task where a scope is highly valuable. Extremely (!) valuable.
The only non-scope alternative is to have a processor sample the relevant signals at a high-enough speed and then dump the sampled information in a way that your PC can plot the communication - basically a DIY logic analyzer. No fun and way too costly for a commercial project - this type of data sampling should be limited to hobbyists who just have to cut down on all costs.
The master can decide to run the SPI communication at quite low speeds - so many microcontrollers with hardware-generated SPI can perform sampling of the signals concurrently with the SPI communication - for example by having an ISR read the signals fast enough that you get multiple samples of both phases of the data clock.
The bad thing with above design is that it doesn't show the difference between data signals that are driven high/low and signals that may be floating when the SPI hardware isn't enabled - for example the MISO signal in case the slave doesn't see/accept the slave-select signal. Going the next step - trying to use an ADC to sample fast enough is so complicated that the probability of bugs in the sampling code might be much higher than the probability of bugs in the SPI code that should be tested...