• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 55 subscribers
  • Views 783 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SPI assert fails in SimpliciTI LPC2364 port

George Brindeiro
Intellectual 440 points
Other Parts Discussed in Thread: SIMPLICITI, CC1101

Hi everyone,

I recently ported SimpliciTI 1.1.0 code to my company's target platform, and now I am testing whether it is fully functional.
I am getting stuck in a assert related to SPI, and not really being able to figure out what the problem is.

Around line 373 of mrfi_radio.c, we have:

/* verify that SPI is working, PKTLEN is an arbitrary read/write register used for testing */
#ifdef MRFI_ASSERTS_ARE_ON
#define TEST_VALUE 0xA5
  mrfiSpiWriteReg( PKTLEN, TEST_VALUE );
  MRFI_ASSERT( mrfiSpiReadReg( PKTLEN ) == TEST_VALUE ); /* SPI is not responding */
#endif

I am getting stuck on that last assert. I went into the details of it, and can tell you the following:

1) In the mrfiSpiWriteReg function call, the values are all correct.
     We go past the assert, and call spiRegAccess, where addrByte=0x06, writeValue=0xA5 andreadValue=0x0F.

2) In the mrfiSpiReadReg function call, we see that the write operation apparently was not successful.
     Again we go past the asset, the read and burst bits are properly set. While addrByte=0xC6 andwriteValue=0xDB (correct), readValue=0xFF (reset value).

Any ideas on what might be my problem?
When I tried to have a fast SPI clock, I got readValue=0x0F on mrfiSpiReadReg, which was even worse (as expected).

Thanks,

George Andrew Brindeiro
Robotron Automation and Technology

  • 0
    TI__Genius 14940 points

    The reason you are getting stuck in the ASSERT is the SPI write test has failed.  Since you need to talk to the radio to do any meaningful work with it, it doesn't make much sense to continue after this failure as any other communication with the radio would also be suspect.  The purpose of the assert statement is to catch dynamic errors in a manner you can halt the CPU and take a look at the call tree to see how you got there if need be.  This is generally much easier to debug than simply having your processor reset itself every couple of milliseconds due to an errant pointer or something corrupting your stack.  In this case, it is merely telling you there is a problem with communicating with the radio and it is probably in your best interest to fix this problem before moving forward.

    Since you indicate you recently ported the code, this is a good indication the ported SPI routines are not responding as SimpliciTI expects them to.

    Jim Noxon

  • 0 in reply to Jim Noxon
    Intellectual 440 points

    Hi Jim,

    Thanks for the reply.

    I realize that the ASSERT is there to verify that everything is working as expected, and trap execution there in case it doesn't. Also, it was quite clear from the code that the test was meant to verify that SPI communication is not working. The results I posted showed things were indeed not working correctly, so I was looking for some pointers as to what exactly the problem could be!

    I know that since this is an open forum, you should not assume anything about the poster's background, so you might as well state all those things. But just so you know, these details are well understood by me unless noted otherwise, ok?

    Thankfully, after some careful checking, I realized that the problem was not on my end of the deal -- at least that is what I believe.

    Seems like  during MRFI_Init(), when the SRES reset strobe is sent, no verification is made as to whether the crystal oscillator has stabilized (CHIP_RDYn bit). A simple check using do-while statement solved the problem, by repeating that strobe until that bit was set.

    Perhaps that should be included in the next version of SimpliciTI? Let me know if I am mistaken.

    Thanks,

    George Andrew Brindeiro
    Robotron Automation and Technology

  • 0 in reply to George Brindeiro
    TI__Genius 14940 points

    This is the first I've heard of a problem with crystal stabilization before with respect to communication with the radio.  I'll list this issue in our bug reports along with your proposed solution.

    Thank you,

    Jim Noxon

  • 0 in reply to George Brindeiro
    Intellectual 350 points

    Hi George,

    Your post is very interesting and may describe a problem we are experiencing with a pilot build of boards. Can you give a bit more detail as to how you coded up the solution you have found, in particular where to do the do while polling to see if the crystal has stabilised.

    It would be a great help to us to improve our solution even if we have other underlying production problems.

    Thank you in advance

    Kris

  • 0 in reply to groblak
    Intellectual 440 points

    Hi Kris,

    In mrfi_radio.c, look for SRES in MRFI_Init, and add a do-while statement as below.
    The original code is identical, except for that. 

      /* directly send strobe command - cannot use function as it affects CSn pin */
      do
      {
        MRFI_SPI_WRITE_BYTE(SRES);  
        MRFI_SPI_WAIT_DONE();
      }
      while(MRFI_SPI_CRYSTAL_UNSTABLE()); // GB: SimpliciTI did not verify if crystal was ok

      /* wait for SO to go low again, reset is complete at that point */
      while (MRFI_SPI_SO_IS_HIGH());


    The macro MRFI_SPI_CRYSTAL_UNSTABLE was defined by me in mrfi_board_defs.h as:

    #define CHIP_RDYn 0x80
    #define MRFI_SPI_CRYSTAL_UNSTABLE()  (MRFI_SPI_READ_BYTE() & CHIP_RDYn)


    Hopefully that will help you out. We assume we had that problem because in our board we have to turn on the power through a digital pin for our custom CC1101 transceiver board, as opposed to having it turn on as soon as the board was powered on. That means that the time between power-up and SMPL_Init is smaller, which might mean that we would have to wait a while before it stabilizes. This has not been thoroughly investigated, but it solved our problem and is something that the datasheet suggests we do anyway, so it's good to have it in there.

    Regards,

    George Andrew Brindeiro
    Robotron Automation and Technology 

  • 0 in reply to George Brindeiro
    Intellectual 350 points

    Hi George,

     Thanks for that. Have tried the fix but does not fix our problem.

    We are not sure if we are dealing with a process problem in the manufacture or something in the hardware or software design. As part of a rework of boards they were x rayed and i wonder if this could be an issue or overheating the chips but none of them work after the rework.

    If we get any good data on the cause of our problem we will share it to help others to avoid the pain, but for the moment we are still in the dark.

    Regards,

    Kris

  • 0 in reply to groblak
    Intellectual 440 points

    Kris,

    Sorry to hear about that. I hope you guys get through that technical issue soon.
    Please do keep us posted on anything you find out, all information is useful!

    Regards,

    George Andrew Brindeiro
    Robotron Automation and Technology