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.

RTOS/CC2640: Multiple SPI chip select during OAD

Part Number: CC2640
Other Parts Discussed in Thread: CC2650

Tool/software: TI-RTOS

I'm working on a CC2640 4x4 custom board, ble_sdk_2_02_01_18, CCS 6.2, XDS 200 debugger,

BTool v1.41.16, simple_peripheral_lp_app.

The custom board has two SPI slaves, one for the external flash and another for sensor measurements.

I am running a clean copy of simple_peripheral through the custom board. I am looking at both the SPI

chip select signals on the scope.

BTool is showing the OAD blocks being transmitted, though the OAD with clean simple_peripheral always

ends in a CRC error.

The scope shows the external flash chip select always asserted low. The other SPI slave chip select is

mostly high but also becomes asserted during OAD. Is there a way to prevent this? Code snippets are

appreciated.

Thanks,

Priya

  • Hi,

    In ExtFlash.c, see the function extFlashSelect. This callsPIN_setOutputValue(hFlashPin,Board_SPI_FLASH_CS,Board_FLASH_CS_ON); Board_SPI_FLASH_CS corresponds to a certain pin, as set in CC2650_LAUNCHXL.h. You should check to make sure this is the pin that you want.

    -Nathan
  • Nathan--
    As I said, OAD blocks are being sent out through BTool. I assume this is possible
    only if the external flash is selected correctly.

    All pin define statements in ExtFlash.c are opening the correct custom board file.

    C:\ti\simplelink\ble_sdk_2_02_01_18\src\examples\util\bim_extflash\cc2640\board\cc2650lp\bsp.h
    Custom board pins have been entered correctly here.

    The custom board has its own separate directory and I have
    a pre defined symbol to select it. Links to this file are working as expected in CCS.

    C:\ti\simplelink\ble_sdk_2_02_01_18\src\boards\CC2640_Custom\CC2640_Custom.c


    If there is still a pin conflict caused by the application, it is in a less than obvious place.

    Thank you,
    Priya
  • Hi,

    BTool is simply sending blocks to the target device and waiting for a notification for a request to receive the next block. This just means that the target device was able to successfully write the block to external flash, which doesn't necessarily mean that it was written to the pin that you were expecting. If you are getting a CRC error, then it is possible that the blocks are not getting written to the correct place.

    -Nathan
  • SPI pin definitions were fine everywhere. I made sure the SPI hardware attributes
    were defined identical to the LP board file and this made the problem go away.
    OAD is working on the custom board!

    Thank you,
    Priya
  • Hi Priya,

    Can you explain why changing the H/W attributes resolved the issue? You should be able to use different attrs than the LP and be okay.

    Is this an issue with our code or your custom board file?

  •  I have been wondering if I should re-open an OAD post. When I marked this

    thread answered, OAD worked on the custom board and I was able to connect

    to the sensor after.

    When OAD was tried again after a few days, it doesn't work any more.

    Editing the SPI Hw attributes shows the correct SPI chip select becoming

    active on the scope. Before this, both the slave chip selects were

    being turned on even with a clean simple_peripheral file.

    Running a clean copy of simple_peripheral on the custom board, BTool

    shows all the OAD blocks being sent. In the end, it is unable to complete

    the OAD successfully (screenshot attached).

    The scope confirms that the other SPI slave is off the entire time OAD is in

    process. Maybe the external flash chip select is not being asserted when

    needed in the end.

    Let me know if you have pointers/methods to narrow this problem down

    further. All the custom board pins in the files listed in previous posts

    have been checked and are assigned correctly.

    Thanks,

    Priya