SPI Bug: AddressLength 17-32 do not generate clock correctly

Legacy Legacy AirPrime modules
1

Hi,

Please be informed about a bug that exists OS 6.61 (Open AT v04.10).

In the ADL User Guide included in this version is the Range of the AddressLength indicated with 0-32 bit.

When I used 8, 9, or 16 bit the clock signal messured with a memory oscilloscope was generated correctly.

For the values 17, 24, or 32 bits the number of clock pulses was incorrect. It seems that 16 pulses is the maximum and values above 16 generate (16 - the value) pulses: I saw one pulse for AddressLength=17, 8 for AddressLength=24, and 16 for AddressLength=32.

This does not conform to the document, so either the document or the core firmware does have an error…

static s32 BusHandle = 0xFFFFFFFF;
static adl_busSPISettings_t BusConfig = {
  15,
  ADL_BUS_SPI_CLK_MODE_3,
  ADL_BUS_SPI_ADDR_CS_GPIO,
  ADL_BUS_SPI_CS_POL_LOW,
  ADL_BUS_SPI_MSB_FIRST,
  ADL_IO_Q2686_GPIO_35,
  ADL_BUS_SPI_FRAME_HANDLING,
  ADL_BUS_SPI_DATA_BIDIR
};
static adl_busAccess_t BusAccess = { 0, 0, 0, 0, ADL_BUS_SIZE_BYTE };

...
BusHandle = adl_busSubscribe( ADL_BUS_SPI2, (adl_busSPISettings_t *)&BusConfig );
...
BusAccess.Address = 0x88000000;
BusAccess.AddressLength = 32;
err = adl_busWrite( BusHandle, &BusAccess, 0, puData );
...

Please note, that in this code nothing except the Address is sent over the bus… I doubt, that it will work better if actually data is sent after the address (I haven’t tested it, though…)

Also, I’d like to remind you of the “SPI bus signals - Problems during read”-Bug (http://www.wavecom.com/modules/movie/scenes/forums/viewtopic.php?t=874). Which I think still is not fixed yet.

Best Regards,
Jan

2

Hi Jan

I can confirm that the problem you are describing with address and opcode length greater than 16, is not working. Furthermore it is not working for OS 6.62 (OpenAT v04.21) either. I have managed by fixing the bit structure so it fits with length 16 or less. Not a pleasent way of doing it.

Regarding my earlier problems with adl_busRead, the one you refer to in your post, this has been fixed apparently but new problems with adl_busWrite have been established instead!
Because of the first problem with address and opcode length greater than 16, I have been trying out with adl_busRead and write without using the adl_busAccess_t, meaning:

static adl_busAccess_t BusAccess = { 0, 0, 0, 0, ADL_BUS_SIZE_BYTE };

Instead i fill a local buffer with the needed opcode and address for the communication and afterwards sends the actual databuffer.
An example:

void mmc_WriteToBuffer(u8 *data, u32 nrBytes, u8 bufNumber, u32 bufAddr){
	u8 buf[4];
	adl_busAccess_t *bus_Access;
	bus_Access = &SpiBus_Access;

	//Format: opcode - xxxx xxxx - xxxx xxbb - bbbb bbbb

	buf[0] = BUF1_WRITE;			//Opcode for buffer 1 write
	buf[1] = 0xFF;					//Don't care byte
	buf[2] = (u8) (bufAddr>>8);		//MSB byte of address
	buf[3] = (u8) (bufAddr&0xFF);	//LSB byte of address

	adl_ioWriteSingle(ioParamsPtr->out_handle,ADL_IO_Q2686_GPIO_21,ADL_IO_LOW);

	//SPI bus write opcode and address
	adl_busWrite ( mmc_Handle, bus_Access, 4, &buf[0]);
	
	// SPI bus write data
	adl_busWrite ( mmc_Handle, bus_Access, nrBytes, data);

	adl_ioWriteSingle(ioParamsPtr->out_handle,ADL_IO_Q2686_GPIO_21,ADL_IO_HIGH);
	
	return;
}

This particular way of doing it, works fine for adl_busRead. Observing the datalines with oscilloscope is making sense. But the adl_busWrite is not! It always sends the first byte and then waits for appr. 25-30 usecs to send the remaining bytes.

So we are not there yet :slight_smile:

With regards
Palsson