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.
Kai,
On the F281x devices TI requires the VDDIO rail to be powered before VDD. This is to ensure a proper reset inside of the device during power up, particularly with respect to the flash. Unfortunately, powering up VDDIO first on these devices allows the output buffers to drive (usually low, but possibly high) during the power up procedure. Once the device is fully powered and the device receives its first clock pulse the output buffer will be turned off. However, there are weak internal pullup circuits on these pins, so they should weakly drive high until code starts and configures them. On later devices TI created a power sequence to keep the I/Os from glitching, eventually removing all power sequencing on the latest devices. They also removed the pullups on PWM pins on later devices. However for the F281x series you have to protect your predrivers externally during powerup.
Regards,
Dave Foley
Dear Dave Foley,
Be so glad to receive your answer! I think I've got the key !
But there is still another thing reserving to be concerned:
1、when I use the program "Example_281xEvPwm.c" provided by TI,everything is OK,even when Power on Reset. While,once my own program is flashed,the problem comes.
2、According to the above 1,it seems something to be wrong with my own program.However, when my own program is flashed into another chip of F2812, everything turns to be all right,including the procedure of Power on Reset.
Best Regards,
Kai
David Foley said:
Kai,
On the F281x devices TI requires the VDDIO rail to be powered before VDD. This is to ensure a proper reset inside of the device during power up, particularly with respect to the flash. Unfortunately, powering up VDDIO first on these devices allows the output buffers to drive (usually low, but possibly high) during the power up procedure. Once the device is fully powered and the device receives its first clock pulse the output buffer will be turned off. However, there are weak internal pullup circuits on these pins, so they should weakly drive high until code starts and configures them. On later devices TI created a power sequence to keep the I/Os from glitching, eventually removing all power sequencing on the latest devices. They also removed the pullups on PWM pins on later devices. However for the F281x series you have to protect your predrivers externally during powerup.
Regards,
Dave Foley
Dear Dave Foley,
Be so glad to receive your answer! I think I've got the key !
But there is still another thing reserving to be concerned:
1、when I use the program "Example_281xEvPwm.c" provided by TI,everything is OK,even when Power on Reset. While,once my own program is flashed,the problem comes.
2、According to the above 1,it seems something to be wrong with my own program.However, when my own program is flashed into another chip of F2812, everything turns to be all right,including the procedure of Power on Reset.
Best Regards,
Kai
David Foley said:
Kai,
On the F281x devices TI requires the VDDIO rail to be powered before VDD. This is to ensure a proper reset inside of the device during power up, particularly with respect to the flash. Unfortunately, powering up VDDIO first on these devices allows the output buffers to drive (usually low, but possibly high) during the power up procedure. Once the device is fully powered and the device receives its first clock pulse the output buffer will be turned off. However, there are weak internal pullup circuits on these pins, so they should weakly drive high until code starts and configures them. On later devices TI created a power sequence to keep the I/Os from glitching, eventually removing all power sequencing on the latest devices. They also removed the pullups on PWM pins on later devices. However for the F281x series you have to protect your predrivers externally during powerup.
Regards,
Dave Foley
Can you send a scope plot of the power up depicting VDD, VDDIO, PWM pin, and X2 for both a "good" power up and a "bad" power up? That might help me determine what is going on. What I'm looking for firstly is whether the glitch on the PWM pin occurs before or after code starts running. If it is before, I'd say it is coincidence that it seemed to work better with the TI code vs. your code. I suspect if you repeated the experiment enough times it would not show a significant difference. If the glitch is after the code starts then we need to align it to an instruction in your code.
Regards,
Dave Foley
Thank you very much for your answer!
As your suggestion, Last night I observed two scope plots of the power up depicting VDD, PWM pin, one of which is under my own code flashed in F2812 and the other is under the TI code.
They shared the same phenomonon in the first 20ms and became very different from each other after the first 20 ms.
Abviously,it has none bussiness of the power up and it drives me to make further research on the difference of the two codes.
At last, I find the key: in my code, there is a waiting time, in which I have kept the T1CNT=0 and the T1CMPR=0 for a "long" time but the TCMPOE=1.
This configuration leads to uncertainty of the PWM pins in the waiting time, sometimes it is high and sometimes it is low.
If the PWM pins can keep low(initial status) at the station of " T1CNT=0; T1CMPR=0 ; TCMPOE=1", I think it'll be more reasonable.This is a bug for F2812 or just designed for ?
Regards,
Kai Wang
Kai,
I'm not sure why it is sometimes high and sometimes low. I'm not familiar enough with the PWM function on this device to tell you if this is expected or not. If you want to ensure the pin stays low initially you can always configure it as a GPIO output low during your wait time. Or perhaps configure the T1CMPR register to a non-zero value before enabling the output. I'm not sure if that would fix your issue or not.
Regards,
Dave Foley
Thank you for your suggestion. In fact, I have configured it as a GPIO output low during my wait time, up to now, everything seems to be OK.
Regards,
Kai Wang