This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I2C0 Slave Boot Mode

Other Parts Discussed in Thread: AM1808

Hello.  We are trying to get an AM1808 to boot in i2c0 slave mode without much success.  I am running on linux, using USB to a Cypress device to interface with the AM18 via I2c.  I am following the directions to create the host AIS interpreter from the spraba5a.pdf document, Chapter 7 (booting from an external master host).  

I have verified that the boot mode register is 00000001 (I2C0 Slave).

I can successfully send the XMT_START ("XS"), and get an ACK back.

However, when I go to read the 2 byte RECV_START back, I never get a response (USB eventually times out on the host). 

When I attach to the device via the jtag debugger and run, then stop after my host times out, the XSMT field of the ICSTR register shows Underflow (don't know if this is meaningful or not).

 

Note that my Cypress/USB/I2C protocol works just fine with the AM1808 as an I2c slave device; I can read and write all day long with no problems, its just when I try this particular boot mode that I can't seem to get past the first read.

Are there any examples available of an I2C AIS Interpretor?  Is source available for the I2C0 Slave boot loader? 

Thanks in advance for any advice.

Dean

 

  • Dean,

    We don't have complete source code for an I2C boot master, but we do have source code that shows how to parse an AIS file and act as the external boot master.  If you downloaded the ZIP file associated with the bootloader app note (i.e. the AISgen installer), then you already have this file.  You should find it in a place like this:

    • C:\Program Files\Texas Instruments\AISgen for D800K006\UartHost\AIS_Util.cs

    This is a C# source file that is part of the UART boot host utility.  You can use it to see the exact steps that are required to boot the device in a slave boot mode.  Please let me know if this is helpful, or if you have additional questions.

  • Joe, thanks for the response.  I had already found the AIS_Util.cs application, but it hasn't really helped me yet as I am unable to get a response from my first request.  Is  the Underflow in the XSMT register meaningful?

    Thanks, Dean

  • Hi Dean,

    When in slave mode, the XSMT_ bit gets cleared when it receives a NACK, a START condition or a STOP condition and the ICDXR has not been loaded with new data since the last ICDXR-to-ICXSR copy.

    In I2C slave boot mode, this bit might not be meaningful b/c the AM1808 slave I2C just waits for the I2C master to send data to it. Was there any data in the ICDRR when you connect the AM1808 with CCS? You might want to monitor the I2C bus to see if it makes any sense.

    Thanks,

    Tai

     

     

  • Hello Tai, thanks for responding.  At the point I pause the process in CCS, my host application has sent the "XS" data (0x5853), and has timed out waiting on the receive.  The ICDRR register shows 0x00000053.  XSMT is 0x0, BB is 0x1, and SCD is 0x1.  If you have any other thoughts based on this data, please let me know.  I'll keep plugging away at it.

    Thanks, Dean

  • Hello Dean,

    Since the AM I2C was getting some data, it means that the I2C is more or less functioning. I am not sure why BB and SCD bits are both 1. I am asking a co-worker to check what the AM is doing next when the I2C got 0x53.

    I will get back to you soon.

    Thanks,

    Tai

  • Dean,

    I want to check one aspect of how you are mastering the I2C transfers during boot.  The correct sequence for the start word synchronization (first step in the boot process) should be something like this:

    [Start] [0x28] [W] [0x53] [0x58] [Stop] ... [Start] [0x28] [R] [0x53] [0x59] [Stop]

    Of course, if you're using I2C1 slave boot mode, then the slave address should be 0x29 instead of 0x28.  You could get into trouble if you are treating the 16-bit transfers as pairs of 8-bit transfers instead, as in:

    [Start] [0x28] [W] [0x53] [Stop] [Start] [0x28] [W] [0x58] [Stop] ...

  • Joe, I think I got it working.  After looking at your sequence, I noticed that I was not reversing the byte order.  After doing this, I got the expected response!  The response I got was 0x53 0x52 which I believe is correct.  (I'm guessing you made a typo with 0x53 0x59).  Anyways I'm off and running again.  Thanks to everybody for their help.   

    Cheers; Dean