• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 15 subscribers
  • Views 893 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LPC 1768: ADC Trim Register Error with VTOR > 0

Daniel Wiese

Hello,

I'm using a NXP LPC1768 Cortex-M3 controller with KEIL MDK-ARM and uLink2-Debugger.

When I start my application from a higher address than 0 (VTOR > 0) the ADC gives back strange values. This is due to the ADC Trim register ADTRM.

During debugging:
When I start my application from address 0x00 (VTOR=0x00), the ADTRM register is 0xF00.
But when I start it from address 0x2000 (VTOR=0x2000), the ADTRM register is set to 0x000. The other application works. I can set ADTRM manually to 0xF00 (although it is not allowed by datasheet), then it works.

Can you explain me that behavior? When is ADTRM set during boot code?
What can I do, to prevent this ADC malfunction?

Thank you for an answer,

DW.

Parents
  • 0

    This was the answer from NXP:


    Hi,

    It is best if the debugger can run through the boot rom after every reset (which will complete the remapping) and then stop at main or in the startup code as the user desires. The ROM sets up reset values of some user registers and also sets internal registers. If the whole boot code does not run before the user code, then the debugging environment won’t represent the run environment as closely as it could, for example having different Flash performance configurations or different reset values of power management registers, which could be misleading.

    There is an option which can be set in the debugger (target options > debug > settings) to stop after the bootloader.

Reply
  • 0

    This was the answer from NXP:


    Hi,

    It is best if the debugger can run through the boot rom after every reset (which will complete the remapping) and then stop at main or in the startup code as the user desires. The ROM sets up reset values of some user registers and also sets internal registers. If the whole boot code does not run before the user code, then the debugging environment won’t represent the run environment as closely as it could, for example having different Flash performance configurations or different reset values of power management registers, which could be misleading.

    There is an option which can be set in the debugger (target options > debug > settings) to stop after the bootloader.

Children