Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH
Problem Description
Issue: DMSC returns stale/incorrect responses for TISCI messages other than VERSION
Platform: J784S4, MCU Domain R5F (MCU_0_R5_1)
SDK Version: [Your SDK version here]
Severity: Critical - Prevents communication with DMSC for non-VERSION messages
Configuration
Secure Proxy Base Addresses
- Target Data: 0x2A480000
- RT (Status): 0x2A380000
Thread IDs
- TX Thread: TISCI_SEC_PROXY_MCU_0_R5_1_WRITE_HIGH_PRIORITY_THREAD_ID (7)
- RX Thread: TISCI_SEC_PROXY_MCU_0_R5_1_READ_RESPONSE_THREAD_ID (6)
Host Configuration
- Host ID: TISCI_HOST_ID_MCU_0_R5_1 (4)
Test Sequence and Results
Initial Testing (VERSION message as "hello world")
Test A: Power cycle → send(VERSION, seq=0x01) → receive()
Result: Correct response
- Response: {type=TISCI_MSG_VERSION (0x0002), host=0x04, seq=0x02, flags=0x00000002}
- Magic Header: {magic=0x00000055, rsvd=0x00000000}
- Observation: seq incremented from 0x01 to 0x02 in response
Extended VERSION Testing
Test B: Power cycle → send(VERSION, seq=0x64) → receive()
Result: Correct response
- Response: {type=TISCI_MSG_VERSION (0x0002), host=0x04, seq=0x02, flags=0x00000002}
- Observation: Response seq remains 0x02 regardless of request seq value
- Attempted to force different seq values - no effect observed
GET_TRACE_CONFIG Testing
Test C: Power cycle → flush_rx() → send(GET_TRACE_CONFIG, seq=0x03) → receive()
Result: Wrong response
- Request sent: {type=0x0021, host=0x04, seq=0x03, flags=0x00000002}
- Response received: {type=0x0002, host=0x04, seq=0x02, flags=0x00000002}
- Expected response: {type=0x0021, host=0x04, seq=0x03, flags=0x00000002}
Test D: Power cycle → send(GET_TRACE_CONFIG, seq=0x04) → receive()
Result: Wrong response
- Request sent: {type=0x0021, host=0x04, seq=0x04, flags=0x00000002}
- Response received: {type=0x0002, host=0x04, seq=0x02, flags=0x00000002}
- Pattern: Always receives VERSION response (type=0x0002, seq=0x02)
Power Cycling Protocol
- Board manually powered off before each test
- Power supply disconnected when necessary
- Clean cold boot for every test sequence
Detailed Operation Sequence
1. Flush RX Queue
flush_rx(thread_id_rx):
→ Read RX status register
→ Status count = 0 (queue empty)
→ Perform sequential read of all 64 bytes from FIFO to clear residual data
→ Result: Queue confirmed empty
2. Send Request
send(thread_id_tx, TISCI_MSG_GET_TRACE_CONFIG):
Request Header: {type=0x0021, host=0x04, seq=0x03, flags=0x00000002}
→ Sequential write of message bytes to TX FIFO
→ Write to last register (offset 0x3C) to trigger PUSH
→ TX status shows no errors
→ Result: Write successful
3. Receive Response
receive(thread_id_rx):
→ Read RX status register
→ Status count = 1 (message available - confirms DMSC responded)
→ Sequential read of all 64 bytes from FIFO
Response Header Received: {type=0x0002, host=0x04, seq=0x02, flags=0x00000002}
Expected Header: {type=0x0021, host=0x04, seq=0x03, flags=0x00000002}
Payload Content: Contains ASCII string remnants from previous VERSION response ("1.1")
Key Observations
1. Request Transmission Verified:
- Memory dump confirms correct request structure before send
- TX status registers show successful transmission
- No errors reported by Secure Proxy hardware
2. DMSC Acknowledgment Confirmed:
- RX status count increments from 0 to 1 after request
- Proves DMSC received request and queued a response
3. Incorrect Response Type:
- Received: TISCI_MSG_VERSION (0x0002)
- Expected: TISCI_MSG_GET_TRACE_CONFIG (0x0021)
- Pattern is consistent across multiple attempts
4. Stale Sequence Number:
- Response seq=0x02 regardless of request seq value
- Matches seq from initial VERSION test
- Suggests response is from previous/cached message
5. Payload Data Contamination:
- Response payload contains ASCII remnants: "1.1" (0x312E, 0x3131)
- These match string data from VERSION response
- Indicates response buffer contains old VERSION data
6. Message-Specific Behavior:
- TISCI_MSG_VERSION: Works correctly
- TISCI_MSG_GET_TRACE_CONFIG: Always returns VERSION response
- No intermediate or partial successes observed
Implementation Details Verified
Secure Proxy Access Pattern
- Sequential volatile reads/writes to hardware registers
- Always read full 64-byte FIFO message (16 x 32-bit words)
- Byte-by-byte memory copy for endianness preservation
- Pointer increment for guaranteed sequential hardware access
- No compiler optimizations affecting volatile access
Multiple Implementation Approaches Tested
1. Array indexing with volatile pointers
2. Pointer arithmetic with explicit increment
3. Various byte-ordering and alignment strategies
4. All approaches show identical incorrect behavior
FIFO Management
- Complete 64-byte reads even for shorter messages
- Explicit flush operations before critical requests
- POP confirmation via last register read
- Status register monitoring at each step
Questions for Texas Instruments
1. Message Queuing: Is there a known issue with DMSC message queuing or response ordering on J784S4?
2. Permissions: Does TISCI_MSG_GET_TRACE_CONFIG require special permissions, initialization, or security context that differs from TISCI_MSG_VERSION?
3. Sequence Management: What is the expected behavior for the seq field in TISCI responses? Should it match the request or increment independently?
4. Flush Procedure: Is there a required flush/reset procedure after VERSION requests before sending other message types?
5. Timing Requirements: Are there timing constraints or delays required between sequential TISCI requests of different types?
6. Thread Context: Could the RX thread be receiving responses intended for a different context or boot stage?
7. Boot Stage: Does message support vary by boot stage? Could GET_TRACE_CONFIG be unavailable at this initialization point?
Additional Information Available
Upon request, we can provide:
- Memory dumps (hex) of request and response buffers
- Complete register traces of TX/RX status at each operation
- Hardware configuration details (clock settings, boot mode, etc.)
- Extended test results with additional TISCI message types
Expected Next Steps
We are seeking guidance on:
1. Root cause of incorrect response type
2. Proper initialization sequence if required
3. Any errata or known workarounds
4. Firmware updates that may address this issue (tifs.bin)
Thank you for your assistance in resolving this critical communication issue.
