• State Resolved
  • Locked Locked
  • Replies 24 replies
  • Subscribers 83 subscribers
  • Views 266448 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.

TMS320F28377D: Analog Subsystem Trim Register always read zero even though OTP has non-zero cal values and DEVICE_CAL_LOCATION (0x70280) has code and bootloader isn't bypassed?

Susan Beiter78
Intellectual 660 points
Part Number: TMS320F28377D
Other Parts Discussed in Thread: TMS320F28379D

I have a TMS320F28379D control card and a custom hardware prototype that I am running with essentially the same code, having confined a handful of GPIO pin assignment differences to a header file.  I was having trouble getting both boards to boot from flash, but since solving that problem in another thread, I have run into a problem where I can see the Analog Subsystem Registers on my control card have non-zero trim values loaded at power-on, but the same registers on my custom hardware have zeros in them, as though there is no call to Device_cal (0x70280) from c1brom_system_init() in c1brom_boot.c as part of the bootloader initialization sequence.  I originally thought that this would get solved by booting from flash so that the cal would not get bypassed, but it didn't seem to fix the issue, so I'm back.  :)

I have dumped the OTP memory for both and compared them to be sure that DEVICE_CAL_LOCATION wasn't all zeros or all 1s, since that would prevent the call.  When I single step the assembly code at 0x070280, everything looks to be working the same on both pieces of hardware (although one is trying to load 0x0000.8D63 and the other 0x0000.955E, as one would expect since the TRIM values would be unique per DSP), but on the control card, I can watch the ANAREFTRIMA register update with the values from OTP, while on the custom hardware, the registers simply stay zero, as though locked or prohibited from being written. Is there something that could be preventing the calibration registers from being written on my custom board?  I'm totally stumped.

I'm attaching the OTP dumps from the control card and from the custom hardware as well as a screenshot comparing the analog subsystem registers at the point just after stepping instruction at 0x70296, MOVL @0x36, ACC.  Control card regs are yellow (changed) and custom HW regs stay same.

Thank you!

custom_hardware_otp_dump.zipcontrol_card_otp_dump.zip

  • 0
    TI__Guru 55700 points

    Susan,

    Looking into PARTIDH, it looks like you are using a F28377D instead of F28379D on custom hardware. Am i correct?

    Also, are you able to write into ANAREFTRIMA register manually? Is this the only register that doesn't copy the trim values?

    Regards,
    Manoj

  • 0 in reply to Manoj Santha Mohan
    Intellectual 660 points
    Yes, they don't make a 377D control card, but it is my understanding that the only difference between 379D and 377D is the custom programmable FPGA fabric in the 379D that the 377D doesn't have. I won't have access to the board with the 377D on it again until Monday morning, and I didn't attempt to over-write them manually (on my 379D control card I was able to manually overwrite them to zero and then step thru the cal routine to make sure they were getting written out of the call to device calibration from the boot loader), but I know that ANAREFTRIMA, ANAREFTRIMB, ANAREFTRIMC, and ANAREFTRIMD all were zeros. You could kind of see that the INTOSC1 and INTOSC2 trim registers were not zero though, so presumably those loaded, if they use a similar routine? I don't see a lock control on the ANAREFTRIMx, so it really doesn't make sense to me.
  • 0 in reply to Susan Beiter78
    TI__Guru 55700 points
    Susan,

    I didn't mean to say that 377D would have problem. I just found that difference in your memory dumps. So, just wanted to get confirmation on the device we are talking about.

    Assuming the device is getting powered up right in custom board, you shouldn't see this behavior. So, we ready need to fish around to find what could be the problem.

    1) Write to ADC TRIM registers wouldn't go through if the ADCCLK are enabled. Did you already check whether ADCCLKs are enabled?
    Can you check the status of PCLKCR13 register when device cal code tries to copy trim value into ANAREFTRIMA?

    2) Write to ADC TRIM registers wouldn't go through if the ADC modules itself is disabled in your device. Can you check the status of DC14 register when device cal code tries to copy trim value into ANAREFTRIMA?

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 660 points

    OK, I can try those things first thing on Monday when I have the hardware in front of me again.  I can check the ADCCLK enable register status as well as the ADC modules at that point in the code, but I guess I am wondering why the control card behavior and the custom card behavior would be different - does the boot loader not make sure that it is attempting to do device cal with ADC clock disabled and ADC's enabled?

    I did a quick step thru with my control card to verify that just before calibration is called, the ADCCLKs are disabled (PCLKCR13 = x0000.0000) and ADC Modules are enabled (DC14_1 = 0x0000.000F).  Screen shots are also attached.  I don't have reason to believe the custom hardware behaves differently, but should be straightforward to confirm.  Thanks and have a nice weekend.

  • 0 in reply to Susan Beiter78
    TI__Guru 55700 points
    Susan,

    I agree there shouldn't be any difference with respect to control card / custom board. BOOTROM code configures DC registers and enables ADCCLKs before trim registers are copied by device cal code.

    I'm just pondering upon the possible scenarios on which trim registers wouldn't get copied. As I said before, these steps hopefully help us troubleshoot the problem.

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 660 points

    Hi Manoj, hope your weekend was good!  I was able to get the same information from the custom hardware with the 377D (vs control card 379D) and it is the same, with ADCs enabled (DC14_1 = 0x0000.000F) and ADC clocks disabled (PCLKCR13 = 0x0000.0000).  HOWEVER, while capturing these registers, I discovered that the PCLKCR13 actually changes inside the Device_cal() routine (0x070280) at the instruction on line 070288: 1A3C000F OR @0x3c, #0x000f.  After this line executes, the PCLKCR13 changes to 0x0000.000F, with all 4 ADC clocks enabled.  It is the same behavior on control card and on custom hardware.

    I tried manually forcing the trim registers to non-zero values on the custom card but did not have any luck - the values would just go right back to zeros after I typed in the boxes.  Once I figured out that the clocks were enabling as part of the CAL, I tried this both with the clocks enabled and with them disabled.  It did not seem to matter.  Any ideas of other possible reasons these registers behave as though they are locked?  Also, why does the CAL routine enable the ADC clocks if they need to be disabled in order to write to the registers?

  • 0 in reply to Susan Beiter78
    TI__Guru 55700 points
    Okay, good to know that ADCLKs and ADC modules are enabled. Do you see this problems across multiple custom boards (or) is it just isolated to this one board.

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 660 points
    Was afraid this question was coming next! My system engineer has only brought up a single prototype so far, so I only have the dreaded sample of one. So there is nothing else to try on this particular board that could be preventing the TRIM from working? I can ask him to get another piece of hardware up and running so that we can see, but it may take a little time, so anything we can try with this board would be helpful. We are running code and using ADC and DAC but with perhaps noticeable offset, so DSP is "working" in most regards.
  • 0 in reply to Susan Beiter78
    Intellectual 660 points

    Manoj, System Engineer has brought up a second CPU and single stepped thru code same process.  Same behavior.  OTP device cal routine is pulling slightly different cal values (95d7 vs 955e) that we can see in the code, but analog trim registers never move from zero and cannot be manually over-written.  No idea what the difference is between control card and custom hardware that would cause this. 

    Part numbers and date codes from custom hardware (both boards) TMS320F28377DZWTS  YFC-6AA6SCW

    I've also checked both control card and custom hardware at power-on to see if ClkCfgRegs were different, but both look like defaults:

  • 0 in reply to Susan Beiter78
    TI__Guru 60865 points

    Hi Susan,

    Thanks for the detailed description of the issue.

    I agree that whatever you are seeing is pretty strange.

    How do the other vitals look on your custom board?  Are you otherwise able to load/run/flash code fine?  Are the 3.3V and 1.2V rails stable, including when the CPU is running? Is the PLL locking and can you confirm the SYSCLK frequency by observing XCLKOUT?

    I think it's a long shot, but I've definitely seen some very strange behavior when the device is current starved or overclocked.  

    As far as lock bits, can you see if any of the bits (including reserved bits) in the following register are '1'?:

  • 0 in reply to Devin Cottier
    Intellectual 660 points
    Hi Devin,

    All of the hardware is performing fine other than this issue of not being able to write to the TRIM registers out of the boot loader. You can see in the same screen shots that show the ANAREFTRIMx values that the LOCK register is all zeros. We are running code just fine on all 3 pieces of hardware (1 control card 379d, 2 custom boards 377d) with the exception that the custom hardware has noticeable ADC offset which is what led us deep into the bowels of the Device_cal() OTP code. All of our timing is verified by 20KHz ePWM with SOCA and SOCB set up and converting voltages to roughly the right values and with the correct expected timing, UART communications with our test GUI, among other things. Power supplies are fine and we are pretty far along in application code development, so there is nothing catastrophic going on outside of having no idea why we can't get the trim values copied even after single stepping thru the boot loader, verify the call to Device_cal(), verifying ADCs are enabled, ADCCLKs get enabled by the cal routine, and then watching as the registers refuse to change values on the custom boards but are fine on the control card. The problem became much more obvious as we started using the DACB and DAC and then reading them back on A1 and B1 ADC channels.

    What is the next step for getting deep TI factory help with the issue to determine if it is silicon or something stupid we are doing that is different from the control card and we just don't know it?

    Susan
  • 0 in reply to Susan Beiter78
    TI__Guru 60865 points

    Hi Susan,

    When you assemble the custom boards, are you also flashing custom code to the devices, or are they still stock devices running code from RAM scanned in via the JTAG?

    Do you have the soldering capabilities/tools to solder/desolder  the ZWT parts to do an ABA part swap between the ControlCard and the custom board?  This would pretty decisively determine if the issue is the board or the part (but this is pretty difficult):

  • 0 in reply to Devin Cottier
    Intellectual 660 points
    No, I don't have a BGA repair and replace station, nor would I want to attempt something like that on my dev card since that is where I'm developing all of my code while my system engineer does application level debugging. I don't have a spare to sacrifice.

    The bootloaders on these boards comes from TI C2000 ware. The application code is mine, but we are not yet executing any of my code for the purposes of what we are trying to debug in this instance. We are booting from flash and single stepping the boot loader to try to figure out why device calibration, which should just work, is not doing anything. I have not modified any boot code or built my own bootloader if that is what you are asking. My code starts at the normal user entry point of main(). While we have been doing application level work in that arena, we discovered that the ADCs have a lot of offset when I started programming the DACs and then reading them back using the ADCs. So that is how we ended up back in the bootloader. My original suspicion was that the custom board, because we were originally just doing a RAM build, was bypassing all of the calibration code, but since changing it to a flash configuration, we know that the calibration routines are called, they just don't do anything to the registers. The registers also can't be manually changed from the emulator within CCSv7, even after stepping to the point of EALLOW and making sure ADC clocks have been enabled. All of this is documented over multiple replies on this post.

    With the suggestion to start swapping parts around, it sounds to me like TI E2E community forum feels as though we have exhausted all reasons why the registers would be un-writeable from either your bootloader code or from your emulation tools. Am I understanding this correctly?
  • 0 in reply to Susan Beiter78
    TI__Guru 60865 points

    Hi Susan,

    We can probably sample you another ControlCard and some units from a different manufacturing lot.  Can you 'friend' me on e2e and then send me your email through an e2e private message?

    I think you've done a pretty thorough look at the obvious reasons the register wouldn't be writable.   One thing to note is that the ANAREF trim is not actually gated by the ADC clock registers; analog system control is in its own clock domain and should be writable all the time as long as EALLOW is enabled.  Furthermore, EALLOW does not apply to emulator writes, so you should be able to always read/write this register with the emulator.  That you can't manipulate the register, even with the emulator, is very strange.  

    -----

    Going a little off on a tangent...

    It is also worth noting that the analog references are shared with the DAC modules (REF A with DAC A and DAC B and REF B with DAC C).  However, the reference not being trimmed shouldn't have a catastrophic effect on the ADC or DAC module performance. 

    How much offset error were you seeing?

    The ADC peripheral clock does need to be enabled for ADC offset and linearity trim to be written.  Are these trims making it through? These should also get updated every time you call AdcSetMode()

  • 0 in reply to Devin Cottier
    Intellectual 660 points
    I've queried my sys eng - he has the hardware in his lab and I have the dev card in mine. He says about 30mV of offset? I believe the linearity trim registers were getting properly re-written on the ADC init, but I will verify tomorrow morning. Another difference that just came to mind when you mention that emulators should be able to write proc regs without needing to override protections like EALLOW - I obviously have built-in XDS 100 emulation on my control card. But my custom hardware is using and XDS110, which is pretty low end. We also have access to an XDS200 or 220 (I forget which it is) so if you think it is worth swapping out emulators because perhaps what is really not working is the emulator interface to the analog sys regs, we could try that. I'm not sure if I asked already, but the oscillator trims that also appear in the analog subsys register grouping are not zero - are they written by similar start up code using values from OTP? Once we get these couple of more things double checked, I will talk with my sys eng about what he wants to do in terms of getting parts from a different lot. Thanks!
  • 0 in reply to Susan Beiter78
    Intellectual 660 points
    From my system engineer: buffered dac tol is ±10mV offset ±2.5% gain error +6lsb
  • 0 in reply to Susan Beiter78
    Intellectual 660 points
    This morning I have verified on the custom hardware that the linearity trim registers load properly on calls to AdcSetMode() in my init routines (this is well after the bootloader can't write the analog subsys trim regs). I have also verified that I can manually over-write GPIOxDAT registers and the oscillator trims (in the same analog subsys reg group) from my XDS110 USB emulator, but NOT the analog trim registers in that group. So processor can't write them from code, emulator can't write them from CCSv7. Have also verified same behavior using XDS220 USB emulator just in case it was the emulator.

    On the issue with DAC, we are using VDAC external reference, not internal. But we are using ADC readback to adjust the DAC to where we need it to be.
  • 0 in reply to Susan Beiter78
    Intellectual 660 points
    After reading an old ADC app note spru812a section 1.8 that talks about code security module and ADC cal, I've also verified that all of the DCSM regs indicate that we are running open and unsecure on the custom hardware at the time that we call the calibration routine.

    The other obvious difference is the built-in JTAG on the control card versus the USB emulator JTAG we are using with our custom hardware - would there be any extra steps that we need to perform to guarantee JTAG access to those registers from the emulator versus the built-in emulation?

    Also wondering if there exists a gel script for doing a dump of all registers (I know, it is a ton!) so that I could easily compare the register settings on my control card versus my custom hardware at the time that the cal is attempting to write the Analog subsystem's trim registers? Not a fun job, but I feel like something is pointing me there versus swapping out components.
  • 0 in reply to Susan Beiter78
    TI__Guru 60865 points
    Hi Susan,

    I think the DAC values you have there are the datasheet tolerances. What are you actually seeing if you measure the output with a good DMM? (including any measured error in the VDAC input)

    Both ADC linearity and ADC offset registers are in a different register space than the ANAREF trim registers, but they are initially loaded by the boot ROM in a similar manner to the way the ANAREF trim registers are loaded. They are also re-loaded (depending on the selected mode) when then AdcSetMode() function is called.

    It doesn't seem likely that the emulator is the problem if you can otherwise read/write/load code through the JTAG.

    The best way to dump large sections of memory is to use the memory browser to navigate to the beginning of the register set(s) in question, then save to file the start address + length of the registers.

    You can also script JTAG read/writes (and most other things that CCS can do) by using 'DSS Scripting', but this will usually take a bit to get setup and working.

    Security shouldn't be blocking these reads/writes, but I'll add the security module expert to the thread assignment to see if there is any way this could happen (it may take him a few days though; he is currently out-of-office).

    If you send me your email we can also review the HW schematic off-forum to see if there is anything that could result in strange system behavior.
  • 0 in reply to Devin Cottier
    TI__Guru 60865 points
    For anyone reading with a similar issue:

    It appears there are 4 undocumented bits in the AnalogSubsysRegs.Lock register that can lock the 4 analog reference trim registers. These are bits 26:23. Somehow, these write-once bits must be being set erroneously by the boot ROM, the custom code that has been flashed, or some interaction of the two.

    I’ve submitted for these bits to be added to the documentation.

    Debug is continuing off-line. I will post an update when a resolution is achieved.
  • 0 in reply to Devin Cottier
    Intellectual 660 points

    If the lock bits look like all zeros when peeking with the emulator, can these undocumented bits still somehow be set?  Similarly, can they be over-written using the emulator or is the only fix something that will be provided in a future C2000 ware update?  Thanks!

  • 0 in reply to Susan Beiter78
    TI__Guru 60865 points

    Hi Susan,

    The lock bits are write-once, so once you write a '1' to them, it shouldn't be possible to change them back unless you reset the device.  However, they should read back '1' after the lock has been initiated. 

    Based on the very specific nature of the locking these bits seem like the likely root cause (but I can't explain why you can't read-back the '1' in the lock register).

    What happens if you lock one of the other bits (e.g. Temp sensor lock bit).  Can you read it back?

     

  • 0 in reply to Devin Cottier
    TI__Guru 55700 points
    Susan,

    Is this issue resolved? Can I close this thread?

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 660 points

    The offline debug revealed that my co-workers CCSv7 install was missing a fix for an xml file defining the register addresses in the analog subsystem.  I will mark this reply (mine) as the resolution.  This was the email exchange, relevant parts excerpted:

    From me:

    In the process of trying to confirm whether or not the lock bits differed between the control card and the custom card, we inadvertently found an anomaly between the two configurations that might offer an explanation for the problem, although we still don’t know how to fix what we are seeing.

     

    On the control card from CCSV7 and using the built-in XDS100 JTAG emulation, when I display the registers for the analog subsystem and the memory at 0x5d180, they match / align and agree with the data sheet definitions symbolically.  However, when we do the same thing on the custom hardware from CCSv7 and using the XDS110 USB JTAG emulator, when Ian displays the registers for the analog subsystem and the memory at 0x5d180, there is an offset of 0x20 for all the symbolic register names and the emulator register display seems to be using the symbolic mapping, not the raw addresses and offsets?  You can actually see that the non-zero OTP value of 0x0000.955e for the analog A reference trim that we have been seeing in the single step through the calibration code is located properly at address 0x05d1b6 (0x5d180+0x36), but the emulator is looking for it at the wrong location, as given by the symbol AnalogSubsysRegs_ANAREFTRIMA at 0x5d180+0x20+0x36 = 0x5d1d6.  This explains why we can’t change the value using the emulator, since that is not a valid location in the register file for writes.

     

    From Devin in response:

    It looks like there was an issue in the xml file that defines the register base addresses in CCS.  A fix to this was previously pushed, so it looks like the custom board development environment is out of date.  On that setup, can you check the current version of the C2000 support files by using:

    Help->Installation Details

     

    And then looking at the version of “TI C2000 Device Support”

     

    You should then be able to update the support files with the menu options:

    Help->Check For Updates

     

    After that you can again check the support file version.  I think the most recent version is 4.2.4.0.

     

    From your email it does look like the analog trims are being loaded, so you may want to start a new e2e thread to debug the analog performance if it is still an issue.