F28335 XINTF read and write operation

Hi Jaiganesh

external data lines have some stray capacitance, so when you do a write, these lines get put in certain state, and it takes quite a while after XINTF releases them to return to high or low state (depending whether you have any pull ups or downs on these lines). Put a scope on a couple of lines and you can observe this. If you increase the delay between writing and reading, you should observe that data read, starts do differ from data written)

Regards, Mitja

Hi Mitja,

Thanks for your response. Following are the steps I followed to understand the behavior

1. Write 0x1234 in 0x4002.

2. Write 0x5678 in 0x4004

3. Write 0xABCD in 0x4006

Since, the data lines have got different data at each write operation, I was expecting data corruption when I perform read from these location.

But, when I read back the data in 0x4002 after 1ms, I was able to read the exact data 0x1234 from that location.

Also, before reading from 0x4004, I put the breakpoint and modified the contents to 0xA0A0 in memory window of CCS.  I was reading the modified data 0xA0A0 instead of 0x5678.

My question is do we have 'back-up' of all these write/read operation in on-chip location "0x4000 - 0x5000" that is reserved for XINTF Zone-0.

F28335 data sheet says  that locations "0x2000 - 0x5000" are reserved under on-chip memory column.

Please clarify.

Thank you,

Jaiganesh

HI Jaiganesh

there are two possibilities:

1. you are reading from the same address just after you wrote to it, so the data lines are still in previous state (I am not sure of the exact program flow of your code)

2. Compiler optimizes the read-back out, as it knows what you have written to the address, a few lines of code earlier. Examine assembly output and try declaring the address volatile

Mitja

Hi Mitja,

I am writing into that address in one function. After 1 ms delay, i am reading back from the address in different function. Also the external data lines are shared across several devices before I come back and read from this location.

I am using keyword volatile also.  Before reading,  I tried to modify the contents in CCS memory window and I am reading the modified data. It proves that the I am not reading the data that is in Data lines.

Is there any documents/links that clearly explains the XINTF apart from SPRU949D.

Thank you,

Jaiganesh

TI,

For F28335 XINTF - is there a spec for bus turn-off time?  Customer doing back/back read, asynch, NO ready, NO hold.   How long between reads ?

Is this turn-around or turn-off time programmable?

Thanks.

All,

Is there any answer to my query? How I am able to read back the data?

Jaiganesh Jayaraman76473 said:

My question is do we have 'back-up' of all these write/read operation in on-chip location "0x4000 - 0x5000" that is reserved for XINTF Zone-0.

F28335 data sheet says  that locations "0x2000 - 0x5000" are reserved under on-chip memory column.

No, there is no backup of the XINTF zone within the device.  Assuming the write is occurring to 0x4000 XINTF something else is going on. 

hi,

Thanks for your response. Our CPLD design doesn't have a logic to read back the data from latch when the address is 0x4002. It has got logic only for write and not for read. In that case, how i am able to read the data back using the instruction

ReadData = *Discout; where Discout = 0x4002

what else could be going on in those reserved locations. How CCS v3.3 is allowing to modify the reserved memory locations 0x4000 - 0x5000. Please clarify as it is a safety critical software. There is a 2ms delay between write and read cycles. 

Hi Lori & all,

Is there any answer to my query? It is important as it is a safety critical software.

Thank you

Jaiganesh,

The only other suggestion I have is to monitor the pins to make sure you really are reading from the XINTF zone (read strobe, chip select) and you don't see anything being driven back on the data pins themselves.    

As others have mentioned, when not driven the data pins will settle to some state (likely the last thing that was driven onto them) but it looks like you have written to a number of locations with a number of different values before coming back to perform the read. 

-Lori

Lori,

I am trying to replicate the scenario on the eZdsp F28335 development board. When I viewed the contents of memory locations 0x4000 - 0x5000, it was all filled with 0xFFFF. Also, when I tried to modify these locations, it didn't allow me to do so as expected.

However in our actual system, when I viewed the memory locations 0x4000 - 0x5000, they all contain some garbage data and when I tried to modify the contents, it just got modified and I could read back the modified value.  How this happens? 

Lori,

I am still looking for some answers. I am not able to understand the behavior in CCS v3.3. In our actual board, is it reading the status of data bus physically and displays it on memory window. Why the data is displayed as 0xFFFF in case of development board as it doesn't have any data lines connected to actual device. 

As you indicated, I have done several writes to different locations in 0x4000 - 0x5000 before reading the data back.

Thanks,

Jaiganesh

Jaiganesh Jayaraman76473 said:

Why the data is displayed as 0xFFFF in case of development board as it doesn't have any data lines connected to actual device. 

The Data pins are floating high due to the internal pull-up resistors. Disable the internal pull-up resisters using the GPCPUD register.

Jaiganesh Jayaraman76473 said:

As you indicated, I have done several writes to different locations in 0x4000 - 0x5000 before reading the data bac

One thought - did you define what you are pointing to as volatile in the C code? 

Of course this wouldn't explain the memory window holding the contents. If the pins are floating I would expect the memory window read to repeat whatever value the pins float to (likely the last value written).

Lori,

Yes, the pointers are defined as volatile only as shown below

volatile Uint16* const DiscOut = (volatile Uint16 *) 0x4002;

"If the pins are floating I would expect the memory window read to repeat whatever value the pins float to (likely the last value written)."

Does that mean each memory window will hold the contents whatever it was written into. In our code, only 0x4002 and 0x4003 are used and declared as volatile. What about rest of the memory locations, say 0x4004. We are not using it. How we are able to read back from that location as we are not defining that location as volatile?

Jaiganesh Jayaraman76473 said:

"If the pins are floating I would expect the memory window read to repeat whatever value the pins float to (likely the last value written)."

Does that mean each memory window will hold the contents whatever it was written into.

When an XINTF read is performed, the data pins are inputs.  If nothing is driving the pins (plus there is no pull-ups internally enabled, no pull-up or pull-down on the board) then the pins will float to some voltage level.  If nothing occurs to change that level, then every read that code composer performs would likely yield the same value.   I say likely because some pins may be at a voltage such that they will read a 1 and cross over to read a 0. 

I had hypothesized that this might be the last value driven on the pins - however it could be any value.  

I found an ezdsp and my pins are floating to 0x2040 when they are not driven as seen in the memory window. If I refresh the memory window those two pins that are reading high will now and then read low.

Jaiganesh Jayaraman76473 said:

In our code, only 0x4002 and 0x4003 are used and declared as volatile. What about rest of the memory locations, say 0x4004. We are not using it. How we are able to read back from that location as we are not defining that location as volatile?

If you are reading/writing to 0x4004 in your code, and you do not want the compiler to optimize out the accesses, then it needs to be defined as a pointer to a volatile. 

The Code Composer memory window does not know anything about volatile. It will read from the xintf whenever you do something to refresh the memory window.

-Lori