• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 16 subscribers
  • Views 670 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2543: CC2543

Todd Witters
Intellectual 400 points
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

  • 0
    Intellectual 400 points
    Clarification: last paragraph should read ".... source and DESTINATION address"
  • 0 in reply to Todd Witters
    TI__Guru** 105180 points
    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
  • 0 in reply to JXS
    Intellectual 400 points

    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?

  • 0 in reply to Todd Witters
    Intellectual 400 points
    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?