• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 526 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.

CC2340R5: Reading the MAC address using an SWD connection

Eduardo Fasolin
Prodigy 10 points
Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH,

Tool/software:

Hello,

I'm trying to read the MAC address of a CC2340R5 chip using an SWD connection.

I can successfully retrieve the MAC address using Uniflash by reading the address range 0x4E000058-0x4E00005C, using TI development boards LP-XDC110ET and LP-EM-CC2340R5.

I understand that the MAC address is stored in the FCFG (specifically in .deviceInfo.macAddr).

I have a few questions:

  1. The SACI_CMD_MISC_GET_DIE_ID command returns the Die ID (also stored in the FCFG), and the SACI_CMD_MISC_GET_CCFG_USER_REC command returns the user record. Is there a way to directly access the MAC address, or perhaps access the entire FCFG, using only SACI commands or the Debug Sub-System Mailbox?
  2. I added tracing on the SWD lines to monitor the sequence of Debug Access Port commands used by Uniflash to read the MAC Address. However, when I try to replicate this sequence of commands, I don't receive any return values from the address. I've included the list of commands in the image below. Is there something else I need to do beforehand in order to access the contents at address 0x4E000058?

I am looking forward to hear from you, feel free to ask me any questions.

Regards,

Eduardo

  • 0
    TI__Mastermind 42100 points

    Hi Eduardo,

    Thank you for reaching out. Taking a bit of a step back, can you clarify what the goal is? Are you trying to read the address while on the production line or as part of some automated testing? Understanding the setup and the reason for fetching the address may help us find a more optimal way to obtain it.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 10 points

    Hello Jan,

    Thank you for your quick response! :)

    We intend to read the MAC address while the chip is on the production line. Following this, we plan to flash the firmware into the chip via an SWD connection using the SWDIO, SWDCK, and nRESET pins.

    The firmware flashing implementation is complete, based on the Flash Programming Flows described in the Technical Reference Manual.

    Currently, we are doing the following steps:

    1) Transitioning the sensor from Dormant mode to SWD mode.
    2) Establishing the SWD connection and reading the Debug Port register IDCODE.
    3) Programming the firmware using the SACI Flash Programming commands.

    From what I could understand using the Uniflash functionality, it seems like a good idea to access the MEM-AP and read the memory reserved for the MAC address right after establishing the SWD connection. After this, proceed with the firmware programming.

    Do you have any additional recommendations or steps that could help us achieve this?

    Thank you for your assistance!

    Regards,
    Eduardo

  • 0 in reply to Eduardo Fasolin
    TI__Genius 15535 points

    Hello Eduardo,

    I assume you have already gone through the Users Guide section: Read CC2340R5 MAC Address via UniFlash. I would also suggest taking a look at the following section: Using Device Addresses in BLE5-Stack Applications (Configuring Local Device Address in BLE5-Stack) to see if this is useful as well.

    BR,

    David.

  • 0 in reply to David
    Prodigy 10 points

    Hello David,

    Thank you for your response.

    I had already reviewed the guide on reading the MAC address via Uniflash indeed.

    We have now partially implemented the process using standard ARM DAP accesses, but the process is very slow at the moment. My current approach involves the following steps after programming and reseting the device:

    1. Re-establishing the SWD connection using the standard SWD connection sequence.
    2. Selecting APSEL = 0x0 to access the AHB-AP.
    3. Reading the TAR register at address 0x40000034 (which returns the expected value of 0xC2) – not sure why this is necessary though.
    4. Reading the TAR registers at addresses 0x4E000058 and 0x4E00005C to retrieve the MAC address.

    Note that these steps closely align with the image attached in my initial post, with the key difference being direct access to the MAC address registers, rather than reading the entire memory block starting at 0x4E000000.

    However, I encountered an issue where valid responses from the register access require implementing a retry routine, with the read request being resent up to 80 times. This is significantly slowing down the process.

    Could you advise if there is a specific command or sequence that can be issued to the chip to enable more efficient and direct access to the AHB-AP, reducing the need for extensive retries?

    Best regards,

    Eduardo

  • 0 in reply to Eduardo Fasolin
    Prodigy 10 points

    Something I forgot to mention.

    I've noticed that the MAC address—or any AHB register—only returns a valid value after both the main and CCFG sectors have been fully programmed. If these sectors are unprogrammed, any attempt to access the MEM-AP returns nothing.

    This prevents me from reading the MAC address immediately after establishing the SWD connection, as I originally intended. Instead, I can only do this step after the full programming process. We plan to use the MAC address for traceability purposes throughout the entire process, so accessing the ID right after connection would be the ideal scenario for us.

    Could give me any insights or advice on why the AHB-AP registers might be inaccessible on a blank or unprogrammed device? 

  • 0 in reply to Eduardo Fasolin
    TI__Expert 3561 points

    Greetings Eduardo,

    I have now been able to do some testing of my own on this topic, and I have an explanation for why this is happening. Permissions to read/write memory to the device are settings that are configured through the CCFG (Customer Configuration). When you have a blank device, the CCFG is also blank, which means that reading the memory is not allowed. This in turn leads to the behavior you are seeing where you are unable to read the FCFG, (Factory Configuration) which is what contains the MAC address. The correct procedure to read out the FCFG is to first program the blank device with a valid CCFG, with all permissions to read/write to memory allowed. This can be done by programming the device once, and you can then read the FCFG back.

    Best,
    Achyut Ray