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.

  • TI Thinks Resolved

CC2543: CC2543

Intellectual 400 points

Replies: 4

Views: 528

Part Number: CC2543

I am working on a bootloader for the CC2543 SOC.   I've modified the linker script to divide up the 32K flash as follows:

  • 3K interrupt vector table and bootloader
  • 14K application and vector redirection table
  • 14K new application image
  • 1K reserved for block protection bits.

The application is responsible for writing the new 14K application image (sent by a proprietary debug tool) into the appropriate location for processing by the bootloader, and then triggering a software reset

The reset vector has been modified to point directly at the bootloader, so it executes prior to the application.  The bootloader checks the integrity of the new application image, and if it has a proper CRC, it will be copied into the application space.

In the bootloader, I'd like to use the DMA to copy the 14K new application image into the 14K of application space.  Is this possible when both the source and address reside in flash?  If so, is there sample code available?

Thanks in advance for your help...

Todd Witters

  • Clarification: last paragraph should read ".... source and DESTINATION address"
  • In reply to Todd Witters:

    Hello Todd,

    Please see 6.2.3 DMA Flash Write in the CC254x User Guide SWRU191. DMA flash writes require the source data to be in XDATA.

    Best wishes

    Please click the "This Resolved My Issue" button on this post if it answers your question

  • In reply to JXS:

    From Section 2.2 of that document:

    XDATA. A read-and-write data memory space, access to which usually requires 4–5 CPU instruction cycles. This memory space addresses 64 KB. Access to XDATA memory is also slower than DATA access, as the CODE and XDATA memory spaces share a common bus on the CPU core, and instruction prefetch from CODE thus cannot be performed in parallel with XDATA accesses.

    Figure 2.1 in that same document shows a 32K Flash Bank within XDATA  memory space.  Is this a mapping of the internal 32K program space?  If not, what it is?

  • In reply to Todd Witters:

    Also found this in section 2.2.1:

    The upper 32 KB of XDATA is a read-only area called XBANK (see Figure 2-1). Any of the available 32
    KB flash banks can be mapped in here. This gives software access to the whole flash memory. This area
    is typically used to store additional constant data.

    Doesn't this indicate XDATA can be used to read the contents of flash?

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.