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.

UCD3138: Questions of UCD3138 reset condition

Part Number: UCD3138

Hi experts,

I'm debugging reset issue with UCD3138128, I know the checksum verification process takes at least 10ms when MCU power on,can I use this rule to verify that  is reset or not when PSU was recovering again and again?

The reasons I ask so is  I put debug pin high at initial function,then put debug pin down in background for loop,but I  saw  the interval between 2 high signals is less than 10ms.

  • If you are using a boot flash checksum it will be much faster. Most of the start up time is used to calculate the flash checksum. If the 2k checksum is valid it jumps to pflash right away.

  • Hi Ian,

    Thanks,I will check if the code have bootloader or not?
  • Hi Ian,

    I still want to know if I don't use bootloader for FW download , can I use this rule(10ms verification time) to confirm if that's reset or not?

  • If you're not using the bootloader on the UCD3138 and UCD3138A, it should take about 10 ms for the UCD boot ROM to initialize the part and verify the checksum. During this time, it will typically draw 5 to 10 mA less because running from ROM is a bit more efficient that running from flash.

    So you can use chip current as another way to try to see what is happening if you don't have an I/O line set up.

    Then there will be additional time depending on where it hits the code which resets it.

    On the UCD3138064, the timing is more complicated. For bootloader in the first 2K, it will be very fast, like the UCD3138. For a checksum in the first 32K, it will be about 10 ms, just like the 3138. If the checksum is in the second 2K boot space, it will be a bit longer. If the checksum is in the second 32K, or the whole 64K, it will be about 20 msec, because it will have to go througth the whole 64K

    On the UCD3138128, A64, and 128A, we put in a faster checksum calculation that reads a word at a time instead of a byte so that we can do the whole checksum on the 128K flash in 10 ms or so. So everything else speeds up as well by a factor of about 4. There are still 5 cases:

    2K bootflash - fast
    first 32K - around 3 ms
    first 64K - around 6 ms
    second 64K, all 128K - around 10 ms.

    Reading a word at a time, we went to an 8 byte checksum on these devices instead of a 4 byte one.

    Probably too much information, but a handy reference.
  • I'm marking this as resolved
  • Hi Ian,

    The previous questions has been clarify, actually,I'm still looking for a method that's allow us to verify the nosied reset issue form device side,because there were too many situations that we've met, HW & FW RD had different opinions about the mcu reset,HW could not see the code,they would think if there is FW logic error in code or not? but FW thought that was mcu reset not FW's business,so can I use BP18 waveform to verify if there is noised reset or not?
    if i saw that BP18 has dip in psu work run condition,I can be sure there is HW reset by noise,reight? cuz I knew the start up process of mcu needs to re-calibrate BP18 to 1.8V.

    Is BP18  waveform a standard of judgment for reset?

    thanks. 

  • I've never looked at BP18, but I don't think that a reset would have much effect on it.  The reset from the processor is very quick, and there is a capacitor on BP18, so I wouldn't expect it to change at all.  

    I always clear the checksum, or don't program it at all.  That way the processor will halt and not restart, so the fact that it reset is very very clear.  It can't be argued with.