• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 52 subscribers
  • Views 3316 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.

CC2642R: OAD guide

Anders Lange
Genius 14355 points
Part Number: CC2642R
Other Parts Discussed in Thread: CC2640

Hi.

Do TI offer any guides on how to implement OAD on CC2642?

I am aware that there is a guide available for CC2640, but have noticed a few things that do not match the CC2642 SDK.

I am using a different flash than present on the Launchpad, the Simple_peripheral_oad_offchip works on the Launchpad, but I will need to port to my specific board.

The ExtFlash.c seems to hold data for 4 different SPI flash implementations, but these do not fit my HW.

Could you point me in the right direction, on how to do this?

BR

Anders Lange

  • 0
    TI__Mastermind 39800 points
    Anders,

    Have you referenced the following SimpleLink Academy? At a high level, it sounds like everything you're looking for.
    dev.ti.com/.../ble_enhanced_oad.html
  • 0 in reply to Evan W
    TI__Genius 14355 points
    Hi Evan.
    Thanks for the response.
    After a quick review of the Simplelink Academy, I dont see any training of using OAD with an external flash thats not supported out of the box.
    The OAD is working on the Launchpad, but needs to modified to work with a different external flash.

    BR
    Anders
  • 0 in reply to Anders Lange
    TI__Mastermind 39800 points
    Anders,

    Instead of looking into ExtFlash.c, look into the CC2642 BLE Simple_peripheral_oad_offchip example uses the NVS Driver for external flash. You can see this in the application project under OAD>flash_interface_ext_rtos_NVS.c

    So it comes down to two options:
    1) If you are using JEDEC flash, the commands should work and you should just need to modify the pinout and the size which is covered under the NVS driver board file
    2) If your flash doesn't accept JEDEC commands, you may need to spin something up on your own to interface with it.

    Looking at the NVSSPI25x.h documentation in doxygen located here:dev.ti.com/.../_n_v_s_s_p_i25_x_8h.html
    There seems to be a number of devices supported. Are any of these what you're working with?

    In the doxygen doc above, there is some more information on adjusting pinout etc as well.
  • 0 in reply to Evan W
    TI__Genius 14355 points
    I do think my flash is covered by the NVSSPI25x.h. In fact it’s the same manufacturer and type as what is used on the Launchpad CC2642 board, it only differs in total size and as a consequence also in some internal configuration, but page/sector sizes are the same, and it has a JEDEC interface.

    But I still have a problem navigating the code. Is it possible for you, with a reference to the simple_peripheral_oad_offchip example, to point me to the file(s) I have to change to do the following:

    Change total size of flash, if needed? The control struct do not seem to hold such a parameter, so perhaps the driver can handle that on it’s own?

    Change pinout. Besides the SPI interface, I will also like to change/remove some LED’s, buttons and the UART. E.g. is all pinout controlled by the file CC26X2R1_LAUNCHXL.h, in which I can either set a IOID_xx or define a pin as PIN_UNASSIGNED, if I do not want to make use of e.g. the buttons in the example?
  • 0 in reply to Anders Lange
    TI__Mastermind 39800 points

    Anders,

    To change this, you have to reference the board file (CC26x2R1_LAUNCHXL.c). To get to this, int he simple_peripheral_oad_offchip example, you can go to app folder > Startup > board.c > click into the #include "./cc2652r1lp/cc2642r1lp_board.c" file > click into #include "../../boards/CC26X2R1_LAUNCHXL/CC26X2R1_LAUNCHXL.c" and then reference the NVS section. Here you will find the following:

    /*
 *  =============================== NVS ===============================
 */
#include <ti/drivers/NVS.h>
#include <ti/drivers/nvs/NVSSPI25X.h>
#include <ti/drivers/nvs/NVSCC26XX.h>
#if defined(USE_FPGA)
#include <ti/drivers/nvs/NVSRAM.h>
#endif // USE_FPGA

#define NVS_REGIONS_BASE 0x48000
#define SECTORSIZE       0x2000
#define EXTFLASH_SECTORSIZE 0x1000
#define REGIONSIZE       (SECTORSIZE * 2)
#define VERIFYBUFSIZE    64

#if defined(USE_FPGA)
// Reserve RAM buffer for OCRAM
#if defined(__TI_COMPILER_VERSION__)
#pragma DATA_ALIGN(ramBuf, SECTORSIZE)
#elif defined(__IAR_SYSTEMS_ICC__)
#pragma data_alignment=SECTORSIZE
#elif defined(__GNUC__)
__attribute__ ((aligned (SECTORSIZE)))
#endif
__no_init static char ramBuf[REGIONSIZE] @ 0x20002000;
#endif // USE_FPGA

// Customization: Only OAD needs SPI
#ifdef NVSSPI
static uint8_t verifyBuf[VERIFYBUFSIZE];
#endif // NVSSPI

/*
 * Reserve flash sectors for NVS driver use by placing an uninitialized byte
 * array at the desired flash address.
 */
// Customization: NO_OSAL_SNV removes NVS flash region
#if !defined(NO_OSAL_SNV)
#if defined(__TI_COMPILER_VERSION__)

/*
 * Place uninitialized array at NVS_REGIONS_BASE
 */
#pragma LOCATION(flashBuf, NVS_REGIONS_BASE);
#pragma NOINIT(flashBuf);
static char flashBuf[REGIONSIZE];

#elif defined(__IAR_SYSTEMS_ICC__)

/*
 * Place uninitialized array at NVS_REGIONS_BASE
 */
static __no_init char flashBuf[REGIONSIZE] @ NVS_REGIONS_BASE;

#elif defined(__GNUC__)

/*
 * Place the flash buffers in the .nvs section created in the gcc linker file.
 * The .nvs section enforces alignment on a sector boundary but may
 * be placed anywhere in flash memory.  If desired the .nvs section can be set
 * to a fixed address by changing the following in the gcc linker file:
 *
 * .nvs (FIXED_FLASH_ADDR) (NOLOAD) : AT (FIXED_FLASH_ADDR) {
 *      *(.nvs)
 * } > REGION_TEXT
 */
__attribute__ ((section (".nvs")))
static char flashBuf[REGIONSIZE];

#endif
#endif // NO_OSAL_SNV

/* Allocate objects for NVS and NVS SPI */
NVSCC26XX_Object nvsCC26xxObjects[1];
#ifdef NVSSPI
NVSSPI25X_Object nvsSPI25XObjects[1];
#endif // NVSSPI
#if defined(USE_FPGA)
NVSRAM_Object nvsRAMObjects[1];
#endif // USE_FPGA

// Customization: OSAL_SNV==1 causes error on 26X2 devices
#if (defined(OSAL_SNV) && (OSAL_SNV == 1))
#error "Only 2 page SNV is supported on 26X2 devices"
#endif // OSAL_SNV == 1
// Customization: NO_OSAL_SNV removes NVS flash region
#if !defined(NO_OSAL_SNV)
/* Hardware attributes for NVS */
const NVSCC26XX_HWAttrs nvsCC26xxHWAttrs[1] = {
    {
        .regionBase = (void *)flashBuf,
        .regionSize = REGIONSIZE,
    },
};
#endif // NO_OSAL_SNV

#ifdef NVSSPI
/* Hardware attributes for NVS SPI */
const NVSSPI25X_HWAttrs nvsSPI25XHWAttrs[1] = {
    {
        .regionBaseOffset = 0,
        .regionSize = 0x100000,
        .sectorSize = EXTFLASH_SECTORSIZE,
        .verifyBuf = verifyBuf,
        .verifyBufSize = VERIFYBUFSIZE,
        .spiHandle = NULL,
        .spiIndex = 0,
        .spiBitRate = 4000000,
        .spiCsnGpioIndex = CC26X2R1_LAUNCHXL_GPIO_SPI_FLASH_CS,
    },
};
#endif // NVSSPI

    I believe this has most, if not all, of the parameters you are looking for. You can also remove the LEDs, uart buttons etc in the rest of the board file. However, since you'll be making extensive edits to the board file (and the current version is just merely linked into the example via a path in the SDK) it's best to make your own board file. This can be done as described here:

    http://software-dl.ti.com/lprf/simplelink_cc26x2_latest/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/custom-hardware.html?highlight=custom%20board#null

    Let me know if you have any other questions!

  • 0 in reply to Evan W
    TI__Genius 14355 points

    Thank you for that, I think that will be most helpful. I do think I have the pinout for my SPI flash in order, but I have not made it work yet. I have put a logic analyzer on the 4 relevant pins on my SPI flash , CLK, Di, DO and CS, and it seems like the first thing the SW does is to send a DP (Deep Power down) command, while holding CS down, all in order. See the first image below.

     

    The second time something happens (app. 1,5 seconds later) on the SPI interface is a RDP (release from Deep Power down) command, but this time the CS is not changing, see the second image below, and therefore nothing happens. Can you or the backup team point me to what could be the cause of this? I guess it has to do with SPI bus setup, but what could make the DP command work properly, and the RDP command and the rest not?

     

    I am still trying to make the simple_peripheral_oad_offchip project work on my own board, so my best guess would be that I am still missing the last bit of setup with respect to SPI bus, pinout or something like that, but what?

  • 0 in reply to Anders Lange
    TI__Mastermind 39800 points
    Anders,

    Hmm. Odd. Looking in main.c, I see a function called Board_initGeneral();. Jumping into that, brings me to the Board.h file which has a #define pointing to CC26X2R1_LAUNCHXL_initGeneral(). Jumping into that is where I see your DP. But prior to the DP, I see a function called CC26X2R1_LAUNCHXL_wakeUpExtFlash();

    In each of these functions, there is a line for PIN_Config extFlashPinTable[] which has more defines for CS, MOSI etc. Can you check to make sure each function's extFlashPinTable has the proper CS pin you want?
  • 0 in reply to Evan W
    TI__Genius 14355 points

    It seems like the pins are configured in both the CC26X2R1_LAUNCHXL.h and CC26X2R1_LAUNCHXL.c

    Both files needs to changed.

    I would like an explanation if CC26X2R1_LAUNCHXL_SPI_FLASH_CS is used for anything, or for that matter what CC26X2R1_LAUNCHXL_SPI_MASTER_READY or SLAVE_READY are used for. It seems to me that the SPI interface is sort of defined half and half in two places, but there might be an order to this that I do not currently see.

    BR

    Anders

  • 0 in reply to Anders Lange
    TI__Mastermind 39800 points
    Anders,

    Yeah I agree it's maybe not organized that well. I'm not as familiarized with this interface as well so maybe it's as you said, there's more organization behind it that is not clear.

    Having downloaded the schematic of the LaunchPad for CC26x2, it seems that CC26X2R1_LAUNCHXL_SPI_MASTER_READY or SLAVE_READY aren't really used for anything with regards to the SPI Flash and they are just pinned out to the LaunchPad headers to be presumably used by other BoosterPacks.

    CC26X2R1_LAUNCHXL_SPI_FLASH_CS is defined to be DIO_20 which is actually used as the SPI Flash Chip Select per the schematic on the LaunchPad.

    Thinking somewhat out loud here, I believe that the SPI interface is configured half in NVS and half in SPI as with the drivers, when you are doing using SPI Flash you are using the NVS Driver with the SPI interface in the background.

    Whereas, when you use the SPI Driver plainly without any SPI flash, you are just using the physical SPI interface alone.

    That way when you use the NVS driver/SPI Flash, you doing really need to worry about the SPI interface as it's handled all within the driver itself (NVS_write, NVS_read etc.). I hope that makes sense.