• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 7258 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

GPIO state during flash/reset

Tim Woolliscroft

Hi,

I am new to ARM and the KEIl tools so please forgive if Ive missed something basic here.

I have inherited a project using a ADUC7026 and am trying to achieve a tidy up of the project, the issue I am struggling with is:

I have several devices attached to GPIO which should not be turned "on" until the system is fully up and several checks have been passed.
At power on (and during flash) the GPIO on these pins seem to be configured as inputs with the internal pullup enabled? Unfortunately the PCB is configured with logic level NFETS which turn on easily.

I've looked though the start up code and configuration wizard and cant find anything to help me there (can't say i'm an assembler guru though).

Is there anything I can do?

Thanks

Tim

Parents
  • 0

    For most embedded processors you don't have any real choice - the external hardware needs pull-up or pull-down resistors and the external electronics must make sure if it should be designed as active-high or active-low. Because before the processor leaves the reset state, no software in the world can help with the actual pin states.

    In short - any new project must make a check list for all things controlled by the processor. That check list must answer what state is wanted or needed while the processor is in reset, and the hw designer then have to fulfill this requirement.

    It really isn't common with microcontrollers having programmable fuses to force initial specific states of every single processor pin. But looking if your specific processor supports programmable fuses controlling I/O is basically the only route to check. The alternative is to redesign the hardware - modifying the startup code can at best shorten the glitch on the I/O pins after reset is released.

    Adding a pull-down resistor is at least a small hw patch, to override the internal pull-up until your own code has time to change the pin from input to output and actively decide what state you want on the pin.

Reply
  • 0

    For most embedded processors you don't have any real choice - the external hardware needs pull-up or pull-down resistors and the external electronics must make sure if it should be designed as active-high or active-low. Because before the processor leaves the reset state, no software in the world can help with the actual pin states.

    In short - any new project must make a check list for all things controlled by the processor. That check list must answer what state is wanted or needed while the processor is in reset, and the hw designer then have to fulfill this requirement.

    It really isn't common with microcontrollers having programmable fuses to force initial specific states of every single processor pin. But looking if your specific processor supports programmable fuses controlling I/O is basically the only route to check. The alternative is to redesign the hardware - modifying the startup code can at best shorten the glitch on the I/O pins after reset is released.

    Adding a pull-down resistor is at least a small hw patch, to override the internal pull-up until your own code has time to change the pin from input to output and actively decide what state you want on the pin.

Children
  • 0 in reply to ImPer Westermark

    To be honest I expected as much.

    At the moment I am only assuming that the GPIO is acting as input during as the data sheet isn't clear. But this has been the case on previous devices I've worked on (PICs & Atmels).

    Oh well another one for the growing list of hardware modifications on this project.

    Thanks for your time.

    Tim