Edward Jakob1I was informed that the DSPs GPIO pins come up in high-impedance state when they are in reset
A high-impedance pin will go to whatever external level it finds
So, are you sure that the highs/lows you are seeing are actually due to the DSP's GPIOs - or are they being "pulled" by your external circuitry...?
We are using a TMX320F28069 ControlCARD plugged into an Experimenter's Kit. Are the non-ADC inputs and non-ePWM outputs the only ones not pulled up to 3.3V on ControlCARDs?
We've seen the same phenomena on F2809 and F28335 ControlCARDs.
According to the TMS320F2802x ControlCARD schematic, there are no pullup resistors forcing GPIOs (e.g., GPIO19) HIGH at power-up. The only way these GPIOs can come up HIGH is if the TMS320F28xxx is pulling them up.
After successful configuration, the ControlCARDs GPIOs all go LOW. Since this is the case, why can't they simply be LOW immediately after power-up or reset?
Edward,See the following wiki:http://processors.wiki.ti.com/index.php/General_Purpose_IO_%28GPIO%29_FAQ_for_C2000#Q:_What_is_the_status_of_the_GPIO_after_reset.3FBasically, on non-Concerto devices, most GPIO 12-max are set to be high-impendence but with an internal pull-up enabled. More specifics can be found in the "System Control and Interrupts User Guide or section.Thank you,Brett
Thanks, Brett. That answers my question.
Since we have an eCAP1/APWM pin driving a MOSFET gate at power-up, this puts us in an over-current situation.
Is there a technique to reduce the amount of HIGH time on the eCAP1/APWM pin after boot-up? Right now, it takes about 10msec to deactivate the internal pullup after reset or power-up. I'm assuming it takes about 10msec to set up the internal oscillator and PLL prior to configuring the GPIO pins.
The quickest solution would be to add a pull-down resistor on the pin.
You could try optimizing your initialization routine by first having it disable pull-ups and then doing things like PLL initialization etc.
I suspect the delay would be reduced if the GPIO pull-up resistors were deactivated in boot.asm. Still, this will only reduce the delay by 1-2usec. Where is the other ~10msec delay between power-up and software execution coming from?
What is in boot.asm?
boot.asm is code that creates the C environment. It initializes all global and static variables, creates the stack and system heap. It is the code that executes directly after the system comes out of reset. boot.asm resides in rtssrc.zip, which is available from TI.
So you are using a custom boot ROM?
No. The system boots from flash. I simply want to customize boot.asm to configure the GPIOs prior to setting up the C environment.
Ok. I think we are on the same page now. I am not familiar with the specifics of the boot-up process. I will ask someone else to comment on the timing then.
Check Section 5-5, particularly Fig 5-4 and Table 5-8, of the datasheet. I looked at SPRS698C. This might have the information you are looking for.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.