• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 645 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

VDD shorts

TM4C1294KCPDT: SS1/SS3 higher POR sample values

Genatco
Guru 55913 points
Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: REF2033

Related to  VDD short issue occurring POR sample values DC volts, MCU temperature are 1.75% times the real values. Somewhat confused how a new MCU has similar readings, then values return to normal there after with PWM0 activity. Also the PWM0 GEN0 SS1 triggered interrupts simply stop after saving parameters block via flash.c then start again with application PWM runtime activity. Both MCU are behaving in the same way for PB flashing.

How can POR measured values be 1.75% times typical measures but only after POR? Why would flashing users parameter block suddenly stop SS1 interrupts or PWM0 trigger sources? Yet SS1 trigger source (GEN0 trig count load) starts cycling immediately with later PWM runtime activity, we get correct sample measures. Oddly SS0 never exhibited these conditions thus seems to point SS1 not triggering properly after POR, new MCU's. So SS0 is disabled, 8 FIF0 steps only complicates the 4 step scenario by adding excessive POP with tail pointer over/under flow mayhem. Surely connecting PC6 even hot to 3v3 can not cause ADC trigger issues and 1.75% higher POR values, right?

 

  • 0
    TI__Guru**** 190406 points

    Hi,

     Are you PB flashing  to the same flash bank as the code resides?  See below excerpt from the datasheet. If the instruction fetch is held off to the bank then the CPU can't respond to the interrupt.

    When a Flash memory operation write, page erase, or mass erase is executed in a Flash bank,
    access to that particular bank pair is inhibited. As a result, instruction and literal fetches to the bank
    pair are held off until the Flash memory operation is complete.

    BP101 said:
    MCU temperature are 1.75% times the real values.

    You are measuring MCU temperature? Using the internal temp sensor or what? Can't really comment on the 1.75%. If you believe the SS0 has no such problem with the measurement then I will suggest you use the SS0 instead. 

  • 0 in reply to Charles Tsai
    Guru 55913 points

    Hi Charles,

    PBflash.c is TI written application that access flash.c to create, erase and store user parameters in a new area each time. The parameter storage address range is well above the application end address. Adding IntMasterDisable() before and enable after the call to write the user parameter block to flash made no difference. The issue is after flash.c returns control to the application, PWM0 trigger to SS1 stops or the conversion complete interrupt never pends again until the application kicks it by staring PWM commutation.

    The MCU temp sensor is on SS3 trig source TriggerProcessor one second GPTM6 intervals. SS3 reads 30*C until PWM0 runs then 42*C is corrected then 46vdc corrects to be 24vdc. Something happens to VREFP during POR perhaps setting the voltage incorrectly? This has never been a problem until connecting C0+ (PC6) to REF2033, how on earth could that cause this issue?

    Oddly setting C0+ >3v seems to have damaged a brand new MCU some how? Otherwise perhaps solder paste connection VDD/A or GND/A on PCB to blame for higher POR sample values?

  • 0 in reply to Charles Tsai
    Guru 55913 points
    Hi Charles,

    It would appear flashing the user PB somehow affects the VREF voltage to ADC. Loading PB via call after POR the parameters get loaded into SRAM. Reloading PB from GUI call, SS1 sampled voltages change for 24v to 46v and SS3 MCU temp 42*c to 30*c. The exact reverse of POR occurs from that of run PWM0. At least it is more clear what call is causing the mayhem.
  • 0 in reply to Charles Tsai
    Guru 55913 points

    Hi Charles,

    Charles Tsai said:
    When a Flash memory operation write, page erase, or mass erase is executed in a Flash bank,
    access to that particular bank pair is inhibited. As a result, instruction and literal fetches to the bank
    pair are held off until the Flash memory operation is complete.

    Yet NVIC has other ideas when it comes to sequencers, triggered interrupt sources. Oddly IntMasterDisable did not stop SS1 or PWM0 trigging SS1 from rapid fire interrupting cycles during save user PB to flash. Had to disable SS1 and PWM0 GEN0 interrupt prior to reading or writing PB or UARTprintf() was filling Debug info from SS1 INT handler.