• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 2059 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.

Bus faults report reserved memory address space.

Genatco
Guru 55913 points
Other Parts Discussed in Thread: TPS737, TPS735

Core register xPSR = 0Xxxxx.xxx3 hard fault, Exception 11 escalated to bus fault.

NVIC: Bfarv=1, Precise=1, Fault Address 0x4C00.0045 reported just above

EPHY0 (0x4405.4000 - 0x4405.4FFF) in the Reserved memory space (0x4405.5000 - 0x5FFF.FFFF)

 

Diagnosing software faults in Stellaris AN01286 May2012 has no example how to trouble shoot faults in reserved memory. How can this Fault be tracked to any particular C+ source module if we don't know why the memory is reserved and for what or who it has been reserved for.

Are we then to assume EPHY0 owns this reserved address space or has it been reserved for future use?

 

 

  • 0
    TI__Guru**** 244400 points
    Hello BP101

    0x4C00.0045 is not a valid address and hence the Bus Fault condition is valid. What is to be traced is the software module that cause an access to this location

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points

    Hi Amit,

    Perhaps not in the sense the module has direct access to that address yet according to text it is valid for fault status posted.

    The question again is what has ownership of reserved memory range ? suspect EMAC0 does. The PC address seems meaningless unless we could some way traverse PC in disassembly window. So if the stack corrupted or MCU popped to many returns off that would seemingly lead use on a wild goose hunt.

    I suspect that a (continue) in a (while) loop is causing this very random failure. For now have removed the continue but would like to be able to trace areas in code with watch points.

    Any ideas of the proper syntax to set a watch point expression for a loop? 

  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    First is to find the offending function, where it occurs. This is a tedious process and some level of instrumentation may be done by using specific GPIO toggles in parts of the code to see what is being executed and the call stack before and after the function. Once it is isolated, then the same GPIO toggles can be placed in the functions so that when the Fault occurs, the GPIO shall not return to 0.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points

    Hi Amit,

    >>First is to find the offending function, where it occurs. That is difficult to do in a 75k application having hundreds of function calls.

    Haven't yet gone into the stack, diagnostic text (attached) infers it may be misleading for PRECISE=1,  BFARV=1. Have isolated the fault to offending application by jumper on POR, selecting specific applications. One (local IP) never faults yet both areas use the same TCP/IP stack, run together typically faults and run separately IOT always faults after many days so he is guilty. May be pulling apart passing IOT data to a dedicated Host USB to gather the printed tStats. That is not the best plan being the compiler is not happy the application data Struct stats are not defined.

    Added 100uf electrolytic bottom side of between +3v3 JP1 pins and GND (fits nicely) stops more frequent faulting of the offending application.

    Have been following the recommended procedures in this text. 

    Tiva TM4C Diagnosing Faults.pdf

  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101,

    No application debug is easy. I am debugging an issue which happens once in 18 days if I am lucky, but steadily I am getting to it by the same approach.

    If a 100uF cap (which is a huge cap) reduces the apparent fault frequency, then may be the issue is with the power grid on the board.

    Regards,
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Agree 100uf SMT added to only one new LP and past added 33uf same location to older LP's helped reduce USB port random disconnects. Two new LP (LOT:DCODE1544) one with no capacitor faults soon after POR (same firmware) and the two (LOT:DCODE1431), with 33uf fault some time later. The one with 100uf still running but the one NO capacitor has faulted several times minutes after POR. Just added more delay time before raising TX/RX flags prior to ring buffers and it seems happy again. That's with a LWIP Systick 600k count not the longer tick 1.2m count it typically has. So it seems 100uf helps cool possible clocks harmonics or transients.

    My vote is the fault symptom is partly HW related.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101,

    Please note that LP is not a development platform and only a reference platform for evaluation. I would suggest using a dedicated board with required caps. On the LP, the main VDD supply caps are limited.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    If not intended for product development and or evaluation of an intended product should it not then have 40 pin Booster Pack X11 header for prototype development. The "Meet the Tiva" documentation states an evaluation kit for experienced developers. Of course we al know the LP headers and trace runs leading to Booster pack pins act like antennas. So much 2.5Ghz WiFi broadcast this neighborhood it's amazing I'm not glowing.

    This case each launch pad is powered by the USB hubs dedicated wall DC supply @500ma per port. The computers power supply had similar failures as well. The LP has recommended 0.1uf bypass into LDO 2.2uf ceramic output and the USB hub port minimum recommended cap value is 47uf. One would never think Ok lets add more capacitors filters for the program will run correctly.

    There is never a problem of adding components to a LP but we have to be aware certain HW peripheral electrical conditions can lead to SW failures in the target HW. Correct me if wrong but that kind of information regarding acceptable VDD noise/ripple amplitude is not in the electrical specifications of the data sheet.
  • 0 in reply to Genatco
    Guru 55913 points

    May have spotted an incorrect value noise reduction capacitor TPS33733 LDO +3v3 regulator (C19) is 0.1uf. The TPS33533 datasheet states (CNR) should be no more than 10nf or .01uf. TPS737 family.

    In most LDO regulators, the band gap is the dominant noise source. If a noise-reduction capacitor (CNR) is used
    with the TPS735 family of devices, the band gap does not contribute significantly to noise. Instead, noise is
    dominated by the output-resistor divider and the error-amplifier input. To minimize noise in a given application,
    use a 10-nF noise reduction capacitor.

    http://www.radio-electronics.com/info/formulae/capacitance/capacitor-conversion-chart.php

  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101,

    I guess that would be a good place to start.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Notice (Fig.18) TPS33733 Vn RMS output noise (C19/CNR) drops from 76 @0.1uf to less then 30 @0 .01uf. The LP with no electrolytic is still faulting, will change C19 0.1uf to a 0.01uf and report back if any change. That is if can see and work with it under 8 diopter magnification.
  • 0 in reply to Genatco
    Guru 55913 points

    Hi Amit,

    Replacing C19 0.1uf capacitor with 0.01uf made a huge difference in the LP faulting behavior. The 100uf electrolytic LP with C19 0.1uf faulted several times while the LP with only a 0.01uf and no electrolytic is no longer faulting for 44k seconds. Granted there were a few tweaks in SW that behaved differently after .01uf but it is now seemingly much more stable. I had noticed there was low level noise on the +3v3 LDO regulator output (oscilloscope) low millivolts saw tooth shaped wave form.

    There has to be something with the frequency loop response of the LDO +3v3 regulator. Being 0.1uf or 100uf is not reducing the frequency noise level in the same way if C19 is single 0.01uf capacitor and no added 100uf electrolytic. The TPS73733 transient response figure19/20 shows a 10uf on the output (transients) versus C20 a 2.2uf ceramic. That same TPS73735 figure 20 shows 3 values of capacitor C20 and the load transient response for each. The 10uf wins hands down and we had planned 3.3uf ceramic with the TPS735 to drop 5v switching regulator to +3v3.

    The nice thing is they are pin layout interchangeable regulators but the TPS735 has an desirable overshoot clamp on the output. That seems a good thing when powered by a +5v switcher. Yet the TPS737 states is good in a buck regulator powered by a switcher but gives no reason why.