Force Overlap

[AtomSoft]

Im planning on using USB MSD and also need a huge buffer for when USB isnt used...

If i power the Device VIA USB CABLE then i want to use the USB Buffer for USB MSD STUFF
if i power the device VIA external POWER then i want to use the USB buffer for something else...

How can i create another variable to overlap on USB MSD buffer space ?

 

[AtomSoft]

Im seriously starting to really dislike Microchip PICs.... Linker Files and the such... then NEAR/FAR omg...

 

[Gobbledok]

On PIC32's, I have used malloc() and free() to allocate and free large variables.

Not sure whether it is available or worth it for your PIC, though.

 

[nsaspook]

Im planning on using USB MSD and also need a huge buffer for when USB isnt used...

If i power the Device VIA USB CABLE then i want to use the USB Buffer for USB MSD STUFF
if i power the device VIA external POWER then i want to use the USB buffer for something else...

How can i create another variable to overlap on USB MSD buffer space ?

If you mean the 512 byte dataBuffer/FATBuffer. The easiest way to use it would be to create a struture type for your data, create a pointer of that data stucture type and assign the address of the buffer memory you want to use to that pointer. I have not looked at the MSD code but I would guess if you don't use the functions it's internal data buffer memory location should still be free to read or write by other processes.

 

[AtomSoft]

ok having enough space isnt the issue i found out... what could cause this problem with SPRINTF ?

        while(1) //FOREVER LOOP
        {
            getstr_uart(Rxdata,5); //GET 5 CHARACTERS ... WORKS as you can see in image
            memset(TxStr,0,20);    //Clears the buffer (works)

            sprintf(TxStr, "Hello %s!\n\r\0",Rxdata); //[B] THIS SETS THE ENTIRE BUFFER TO 0xFF [/B]

            str2uart(TxStr); //Usually works but jumps out and turns on some leds for some reason... 
        }

 

[nsaspook]

Is 0xDDC (the location of TXStr) a valid data memory address on your chip?

 

[AtomSoft]

Is 0xDDC (the location of TXStr) a valid data memory address on your chip?

Technically yes... but its clasisfied as USB VARS so im trying to this now:

#pragma udata vars
unsigned char TxStr[20];
unsigned char Rxdata[6]={0};
unsigned char Txdata[] = "UART Operational!\n\r\0";
#pragma udata

where vars is GPR1 aka 0x100 to 0x1FF but still i get the same issue... you can see the address changed but all 0xFF still.

 

[Ian Rogers]

What happens without the memset(); command?... I'm just wondering if the function is some how changing the pointer to a rom pointer. as that would cause this effect..

 

[AtomSoft]

Same exact thing without the memset() command.... The only good thing ive done is setup the Linker so its in a good location of memory heh



Tried it like:

&TxStr and TxStr no luck...

 

[Ian Rogers]

Just to see if sprintf requires a const rom pointer .... Go into program code and look at code position 0x100 and see if the code is 0xff ---> 0xff;

 

[AtomSoft]

Not sure how to do that... do you mean this:

 

[AtomSoft]

ok my combined code is huge... mainly becase I have ELM CHAN FATFS in this project... when i remove all the FATFS files it works! but when i add the files back it doesnt... even if i dont call any of the functions from fatfs stuff. I dont even have to INCLUDE them... if they are in the project at all it doesnt work. If i remove them from project its ok... WTF!

 

[Ian Rogers]

OK.... In the linker script is the var data protected? You may have to unprotect the data if its overlapping....

Oh and by the way Yes that's what I mean't.... the locations are all 0xff... Its as if the sprintf() is reading from rom....