Help - Search - Members - Calendar
Full Version: Alternating Memusage
1Emulation.Com > Official Emulator Forums > DSWifi
Mighty Max
Heya, i got a lil' wish SgStair,

I got a structure, that excessive calls new & delete in my main program. This works fine. However as soon as I initialize the ARM9 side of the Wifi lib, These calls fail once of about 300 cycles.

I have put in a memory monitor and noticed that as soon I activate Wifi, the allocated bytes alternate between two values (x and x+8 ), so i assume that you are freeing and allocating 8Bytes regulary, while the DS isnt receiving/sending anything. (Wifi_EnableWifi() wasn't called)

As this isnt much, could you change that behaviour to have these 8 Bytes allocated the whole time, so that there is less chance that the irq'd malloc/new interfere with allocs in the main()?

You can test that behaviour yourself. http://mightymax.org/unnamed_strat.html is loosing its units occasionally when this error occures (It cant add the unit back to the sorted tree). Commenting out the call to InitNetwork (see below) fixes this issue.

CODE
void InitNetwork(void) {
    REG_IPC_FIFO_CR = IPC_FIFO_ENABLE | IPC_FIFO_SEND_CLEAR;
    u32 Wifi_pass = Wifi_Init(WIFIINIT_OPTION_USELED);
    REG_IPC_FIFO_TX=0x12345678;
    REG_IPC_FIFO_TX=Wifi_pass;
    
    TIMER0_CR = 0;
    irqSet(IRQ_TIMER0, Timer_50ms);
    irqEnable(IRQ_TIMER0);
    irqSet(IRQ_FIFO_NOT_EMPTY, arm9_fifo);
    irqEnable(IRQ_FIFO_NOT_EMPTY);
    REG_IPC_FIFO_CR = IPC_FIFO_ENABLE | IPC_FIFO_RECV_IRQ;
    Wifi_SetSyncHandler(arm9_synctoarm7);

    TIMER0_DATA = -6553; // 6553.1 * 256 cycles = ~50ms;
    TIMER0_CR = 0x00C2; // enable, irq, 1/256 clock    
};
sgstair
erm... I'm not aware of any behaviour that could cause it to allocate /deallocate 8 bytes periodically, if you do find something of the sort though, please let me know... As far as problems with allocating, this could happen if the allocate functions aren't reentrant safe.... I should probably look at mitigating factors further.
To prevent any possibility of contamination though, wrap the allocation functions with a layer that temporarily disables interrupts while allocating.
-Stephen
Mighty Max
Just wanted to let you know, that i found the problem, and it was not the fault of the lib. It just increased the chance that this error fatals biggrin.gif due to the timing of the irq's.

Turned out that running recursively through the sorted trees would take up more stack then beeing available. That was no problem as long no IRQ happened, but when it did, part of this too big stack was overwritten (IRQ stack is just blow SVC stack) so the parameters passed to new/malloc were not the correct ones, therefor it failed.

*trying to look innocent*

Mighty Max
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.