Other Parts Discussed in Thread: MSPM0G3507
mspm0g3507 my problem.docxadc12_simultaneous_problem_file.zipHello TI Community Experts and Engineers,
I'm developing an application using the MSPM0G3507 MCU and encountered two distinct issues. I wonder if you could help me solve them:
Issue 1: Fixed Offset in Dual ADC Synchronous Sampling
Goal: Configure ADC0 and ADC1 for synchronous sampling at 1MHz sample rate.
Implementation:
- Using a single trigger source (TIMA0) to initiate conversions on both ADCs.
- Using separate DMA channels for each ADC to transfer results to two separate arrays (e.g., adc1_buffer[], adc2_buffer[]).
- ADC configurations (clock source, resolution, sample-and-hold time, etc.) are identical. ADC clock source is ULPCLK(40MHz)
Problem:
After simultaneous conversion triggered at the same instant , comparing corresponding indexes in adc1_buffer[] and adc2_buffer[].
I observe a consistent fixed time offset between the sampled values at the same index position across the two arrays. Specifically, the value at index n in one array seems to correspond (in timing) to the value at index n+2 or n-2 in the other array, rather than index n to n. The estimated time difference is approximately 2 ns.
Could you help me figure out:
What are the potential causes of this fixed small offset? Could it be related to configuration (trigger synchronization granularity, DMA transfer initiation timing, memory access latency) or an inherent limitation within the chip's architecture?
Issue 2: Debugger Hangs in Infinite Loop at -O2 Optimization
Problem:
When compiling with optimization level -O0 (no optimization), the program runs correctly under the debugger (TI CCS / IAR).
When switching to optimization level -O2:
- The program starts and runs under the debugger.
- After running for some time (after Continue), when I attempt to pause it (Pause), the debugger fails to halt at the expected location.
- The debugger shows the PC pointer stuck at address 0x00000414. Disassembly shows an instruction branching to itself (B 0x414), indicating the program has entered an unintended infinite loop.
- The address 0x414 appears to be within a low memory region associated with the Reset_Handler flow, not within my main application loop.
Could you help me figure out:
Why would higher optimization cause the program to eventually become unresponsive and enter this loop? What are common root causes?
Could this expose undefined behavior (UB) in my code (e.g., uninitialized variables, memory corruption) that manifests differently with optimization?
Could it be related to interrupt handling, stack overflow, linker script configuration, or optimization of specific library functions?
What are effective strategies to debug such optimization-dependent hangs? (e.g., Map file analysis, specific compiler warnings?)
What I've Tried:
For Issue 1: Carefully verified ADC (trigger source, clock divider, sample timing) and DMA configurations (priority, trigger, source/destination, transfer mode) for both ADCs.
For Issue 2: Reviewed differences in generated code/output between -O0 and -O2 (disassembly, map file), but the exact root cause remains elusive. Enabled compiler warnings (-Wall).
Requesting Your Guidance:
For the dual ADC offset: What is the most likely cause of the 2ns discrepancy? How can I verify and resolve it?
For the -O2 hang: Could you suggest common troubleshooting steps or share relevant experiences?
Thank you very much for your time and assistance! I can provide specific configuration snippets (register settings, key functions) or project details if needed, while being mindful of security/IP.
Best regards,