Unable to view SRAM locations in debug

Ok now see table 2-4 Bit banded is memory map 0x2000.0000 - 0x2006.FFFF and Gel shows end is - 0x2003.FFFF.

Accordingly the fault address 0x2AFB.F079 falls in table 204 occurring in Reserved memory range 0x2235.0000 - 0x3FFF.FFFF. How to track that seems impossible.

Oddly strange is table 2-6 bit banding memory region End is 0x2006.FFFF is roughly 458kb. Perhaps table 2-4 is also a memory map should be 0x2003.FFFF?

Hi Amit,

Well if I add a short Delay after sending data to EMAC0 before raising the TX flag true the fault may occur 100000's of seconds versus 100's of seconds later. It don't matter how the EMAC DMA is configured IE: Mix/Fixed burst rates, TX priority, 4,8,16 the fault eventually raises but much sooner without the added delay. Some in forum have suggested the add Delay is not a good solution but my find is internet COMMS are strange animals......

 No registers optimization, LP Immediately faults middle of displaying the Bulk USB client initialization message which is after initialization of ports, timers, PWM, ADC peripherals. Can you tell me what lives at Reserved memory address (0x2AFB.F079) ?? since it is reserved we have no access to even DEBUG it and see the contents.

That said we have to find a solution for what ever is using Reserve space but without knowing what is reserved for...... 

Bulk USB device is last set up before connection is made to Exosite. Added clock lines found Host/Hub to bulk USB device initialization - didn't help.

    //
    // Tell the USB library the CPU clock and the PLL frequency.
    //
    USBOTGFeatureSet(0, USBLIB_FEATURE_CPUCLK, &ui32SysClock);
    USBOTGFeatureSet(0, USBLIB_FEATURE_USBPLL, &ui32PLLRate);

Hi Amit,

Odd thing is USB bus fault does not occur when the most basic register optimization is enabled. The problem with trying to debug USB fault is we have to single step the fault. Do we really need to do that or can we get a good debug session with register optimization level for any Reserve memory faults. NVIC precise landed on 0x2AFBF079  several times but we don't know how to track Reserve memory space other than by trail and error by adding Delays, Boolean flags, etc..

Note worthy is the original HWREGBITW (RX/TX) blocking flags several instruction times long now exist as single instruction high speed Boolean switches. That rolling DHCP event flag was unnecessarily expending 1000's of machine cycles, corrected via single && switch.  BTW that rolling DHCP event call at times locked up our wireless routers DHCP server. We really didn't need to hold off the DHCP calls in LWIP timer call since this block flag takes care of the rolling Exo_Hal DHCP events as well.

Here is the fix (eth_client_lwip.c) / LWIPHostTimerHandler(void):

    }
    else if((g_sEnet.eState == iEthDHCPWait) && (HWREGBITW(&g_sEnet.ui32Flags, FLAG_DHCP_STARTED) == 0)) //BP 4.9.2015 Stop rolling DHCP events.
    {
     

Always diplomatic - Cb1/staff simply (cherish) vendor's (many) "leaky mugs" and "low thread count T-shirts."    

Vacation in OH (2nd time proposed, today (see Attila) - go figure) as likely (& desirable) as (facetious), "RAS/CAS" posting...  

We may consider (when) Johnny Football returns...  (but only at/around 50 Yd Line Field Box & non-vendor (i.e. leak-free) mugs...)

Hi Amit,

For CB1 my rebellious attempt (factious) intended humor not intended as spell check frater. Course we are aware SRAM does not use column/row refresh cycles- hence the uprising posts. The random bus faults (11) seem integral to the GEL file SRAM R/W address range mention several posts above.

Referring back to the datasheet memory map page 103 table 2-4 seems in conflict (useable SRAM) GEL table end address (0x2004.0000). Myself prudently checking said SRAM R/W range several times in the past, discover it incudes protected regions in EMAC0 DMA pBuf tests (Safe) memory space (>=2000.0000 && <= 0x2007.0000) abstraction layer memory constraints. Seemingly disaster occurs anytime pBufs enter address space above 2004.xxx).

Luck would have it Transport pBufs use considerable more bytes for http header allocation than RAW pBufs. It is not documented LWIP 1.4.1 higher up layers append extra bytes to http headers of existing DMA R/W descriptor pBufs. Unless we print LWIP debug stats after LWIP initialization that would not be apparent and slower COMS exacerbate the issue of HEAP space use in excess pBufs entering protected memory space. The LWIP HEAP space has not risen above 8020 max bytes since Friday night and now hangs near 1080 used bytes.

Todays Making that run MCM pickup on a 4 port USB HUB. :-)