project playing up

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guys, I'm still having bother with my project, basically things like structures, malloc/free, and arrays are causing the system to fail.  Its a large project so I don't even know where to begin to correct these errors.  Have a look at the function below.  If I free the memory allocated in the function the system collapses.  If I try to use an array allocated of the stack then I also get the error.

 

void select_partition(struct ff_file * stream, int partition_nr){

	struct mbr_partition * mbr = safe_malloc(512);

	hardware_read_block(1, 0, 1, (char *)mbr, 0);

	if(mbr->BootStrapCode[0] != 0xeb){

		int mbr_location = 0;

		if(partition_nr == 1){

			mbr_location |= mbr->partition_entry1.FirstSector[0];
			mbr_location |= mbr->partition_entry1.FirstSector[1] << 8;
			mbr_location |= mbr->partition_entry1.FirstSector[2] << 16;
			mbr_location |= mbr->partition_entry1.FirstSector[3] << 24;
		}
		if(partition_nr == 2){

			mbr_location |= mbr->partition_entry2.FirstSector[0];
			mbr_location |= mbr->partition_entry2.FirstSector[1] << 8;
			mbr_location |= mbr->partition_entry2.FirstSector[2] << 16;
			mbr_location |= mbr->partition_entry2.FirstSector[3] << 24;
		}
		if(partition_nr == 3){

			mbr_location |= mbr->partition_entry3.FirstSector[0];
			mbr_location |= mbr->partition_entry3.FirstSector[1] << 8;
			mbr_location |= mbr->partition_entry3.FirstSector[2] << 16;
			mbr_location |= mbr->partition_entry3.FirstSector[3] << 24;
		}
		if(partition_nr == 4){

			mbr_location |= mbr->partition_entry4.FirstSector[0];
			mbr_location |= mbr->partition_entry4.FirstSector[1] << 8;
			mbr_location |= mbr->partition_entry4.FirstSector[2] << 16;
			mbr_location |= mbr->partition_entry4.FirstSector[3] << 24;
		}
		stream->partition = mbr_location;
	}
	//safe_free(mbr);
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which AVR are you using, most have a very small ram space so large arrays can be a problem!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ack sure I'm using a SAMA5D44 with lots of lovely 512MBytes of DDR RAM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Instrument your code. Maybe your stack is colliding with your heap? ‘The system collapses’ what does that entail? Do you get an exception?
Read up on stack painting.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Maybe this should be moved to the SAM forums then?

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

d

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Mon. Jun 24, 2019 - 08:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is no where near a finished function.  I was first testing if it worked then I was going to do pointer math to speed it up. Oh and the data is little endian.  The rest they says is history.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fianawarrior wrote:
are causing the system to fail
Two things:

 

1) you keep reporting "system fails" without any clear indication of what that means. It's a bit like me saying "my car won't work - what's wrong?". Far too vague. An engineering fault report will usually contain expected/actual behaviour and the difference will be the main clue to the nature of the problem... e.g.: "can't drive car. expected: four wheels, observed: three wheels" ... solution: "someone has stolen one of your wheels!"

 

2) you should not be testing the "system" at this stage. You should have unit tests to test every individual module. Only when they all appear robust should you consider system integration at which point you can start to run some system tests. With something as complex as an operating system/filing system you can't just write the whole thing as one great amorphous blob, throw the ON switch and expect it all to "just work". Professional software engineering does not work like that!

Fianawarrior wrote:
If I try to use an array allocated of the stack

The POINTER is on the stack, not the malloc() surely? Or are you saying that "safe_malloc()" is really like alloca() rather than malloc() ? If so it is very unusual in this day and age to make stack allocations (almost every famous software exploit involves buffers being over-run on a stack !). Usually malloc() allocates out of a heap.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you should not be testing the "system" at this stage. You should have unit tests to test every individual module. Only when they all appear robust should you consider system integration at which point you can start to run some system tests. With something as complex as an operating system/filing system you can't just write the whole thing as one great amorphous blob, throw the ON switch and expect it all to "just work". Professional software engineering does not work like that!

I do do unit testing, hence I know which particular function is causing the system to fail, as to the failure.  Well I suspect the array bounds are being violated.  Wish I was being violated!  lol

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, since the malloc I use is from git hub, i.e. its not stdlib.h I'm going to look into it has the cause of my errors.  These errors are manifesting themselves in using malloc but worse, when trying to use arrays allocated on the stack in functions the RTOS Fails, as far as I know the Array boundaries are being violated.  I'll know more tomorrow.  Clearly I can't continue to progress in my project until this is sorted.  

 

Oh, I have another error concerning structures, when I add a struct member the system fails, again probably violating the boundaries.

 

God I hate bugs like these.  I've tried tearing the project apart and rebuilding it, I've also tried using a different compiler(s).

 

Slan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Find the root cause! Step through the code and look at what is pointing to where. If you know the bounds of your stack, then it should be obvious if your blowing the stack. Earlier I mentioned 'stack painting'. Memset your stack area with a particular pattern eg 0xDEADBEEF. By doing a memory dump, you can see how much stack your code is using. If you don't find any deadbeef - you know you've overrun your stack.

 

In the TI code examples for their TIVA series chips, they allocate a small stack. Do anything beyond what the app does and it blows its brains. The solution is to increase the stack size.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another approach are "guardbands". Modify your malloc() to over allocate to allow room for a couple of uint32_t on either side of the allocation. Put some cookie value like 0xDEADBEEF, 0xBABEFACE, 0xACEB1ADE, etc into the uint32_t's. Pass the location just after the first uint32_t. When you free(p) look both at the 4 bytes before 'p' to see if that guard is still in place and when you know the requested length of the allocation look at *(p + len) in the following uint32_t and is that guard still in place too? assert() or throw an exception if either guard has been damaged.

 

(just put this stuff into "Debug", don't do it in "Release")

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
...

assert() or throw an exception if either guard has been damaged.

 

(just put this stuff into "Debug", don't do it in "Release")

Leave it in as arm Cortex MMU (SAMA5D44) is built-in (an implementation in hardware instead of software); the best tests are by operators as the test case domain is larger than during unit testing, integration testing, and verification and validation testing.

Though the following is for arm Cortex-M MPU :

Are We Shooting Ourselves in the Foot with Stack Overflow? « State Space

...

 

Designing an Exception Handler for Stack Overflow

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh I missed that this was a Cortex-A with an MMU. In that case you are quite right - the OS should be putting protection on memory allocations made in malloc() so writes outside would throw an exception (like happens in Windows and Linux)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it possible the underlying disk device has a block size larger than 512 bytes? The hardware_read_block() function might be reading more than you are expecting.

Maverick Embedded Technologies Ltd. Home of wAVR and Maven.

wAVR: WiFi AVR ISP/PDI/uPDI Programmer.

Maven: WiFi ARM Cortex-M Debugger/Programmer

https://www.maverick-embedded.co...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good point - many modern devices have switched from 512 to 4096 byte blocks (because both NTFS and EXT3/4 are fundamentally based on 4K blocks)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guys, I've narrowed the bug that prevents me from using arrays to read/write from the sd card.  It fails when I pass a array address, i.e. of the stack, "&array[0] as opposed to * ptr allocated by malloc.

This is the call that fails:

 

void hardware_read_block (char drive, int block, int nr_blocks, char * block_data, int request_time_out){

	sSdCard * lib_local = NULL;

	if(drive == 1){
		if(drv_1 == NULL)
			drv_1 = api_create_rw_semaphore();

		lib_local = &lib1;
		api_read_semaphore(drv_1, request_time_out);
	}
	else{
		if(drv_0 == NULL)
			drv_0 = api_create_rw_semaphore();

		lib_local = &lib0;
		api_read_semaphore(drv_0, request_time_out);
	}

	SD_Read(lib_local, block, block_data, nr_blocks, NULL, NULL);

//	api_delay_task(api_ownID(), kernel_tick / 100);

	if(drive == 1)
		api_post_rd_semaphore(drv_1);
	else
		api_post_rd_semaphore(drv_0);
}

find attached the file it is declared in.

 

Wm.

 

 

Attachment(s): 

Last Edited: Thu. Jun 6, 2019 - 03:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You aren't showing enough context. You mean that?...:

void som_fn() {
    char array[512];
    char *pChr;
    
    pChr = (char *) malloc(512);
    
    hardware_read_block(0, 123, 1, &array[0], 1000); // fails
    hardware_read_block(0, 123, 1, pChr, 1000); // works
}

So are you using a compiler that limits stack size - perhaps it has a linker input where you define STACK=200 or something?

 

What if you do this:

char array[512];

void som_fn() {
    char *pChr;
    
    pChr = (char *) malloc(512);
    
    hardware_read_block(0, 123, 1, &array[0], 1000); // fails
    hardware_read_block(0, 123, 1, pChr, 1000); // works
}

does that "fix" it?

 

Many compilers have fixed limits on stack sizes if they keep separate call/ret and data stacks.

 

(I seem to remember that MSVC for example just allocates a fixed 1MB for a process stack - as long as you don't put huge structures on the stack it's usually enough - don't ask me how I know about this!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You aren't showing enough context. You mean that?...:

void som_fn() {
    char array[512];
    char *pChr;
    
    pChr = (char *) malloc(512);
    
    hardware_read_block(0, 123, 1, &array[0], 1000); // fails
    hardware_read_block(0, 123, 1, pChr, 1000); // works
}

So are you using a compiler that limits stack size - perhaps it has a linker input where you define STACK=200 or something?

 

What if you do this:

char array[512];

void som_fn() {
    char *pChr;
    
    pChr = (char *) malloc(512);
    
    hardware_read_block(0, 123, 1, &array[0], 1000); // fails
    hardware_read_block(0, 123, 1, pChr, 1000); // works
}

does that "fix" it?

 

Many compilers have fixed limits on stack sizes if they keep separate call/ret and data stacks. (I seem to remember that MSVC for example just allocates a fixed 1MB for a process stack - as long as you don't put huge structures on the stack it's usually enough - don't ask me how I know about this!)

Correct Clawson.  The global allocation works.  But I can't see having a large stack size causes a error. In this case the task stack is 16384.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe the MMC SD card write is using the array after I return back to the function thus corrupting the task stack.  I'll check now.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope, its not that. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's a CortexA , surely you can do data breakpoints? Break on whatever's writing the corrupted memory.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do have a J-Link debugger but I hate resorting to that.  The problem only occurs when read/writing to SD_Read/SD_Write using local arrays.  I'll return to it tomorrow after a wee break from searching.  At least I've narrowed the error down.

 

Last error is with adding removing struct members from the following struct.

 

struct ff_file{

	struct EXMaster_Parameter_Block * Bios_Parameter_Block;


	unsigned int cluster_addr;
	unsigned int cluster_nr;
	char * cluster_data;

	struct chain * dir;
	struct chain * data;

	int indexing;
	unsigned int partition;
	unsigned long long file_size;

	char file_name[255];
	unsigned int data_cluster_addr;
	unsigned int data_cluste_nr;
	char * free_data;
	char * ptr_to_data;
};

 

Anyway, I'll be glad to get away from writing this exFAT driver.  Its been nothing but bugs.

Can't wait to learn the USB protocol.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So it looks like you're using the libsdmmc library from atmel-software-package on GitHub.

 

To expand on my previous comment, you might want to verify that SD_GetBlockSize() returns 512 for your SD card.

 

Steve

Maverick Embedded Technologies Ltd. Home of wAVR and Maven.

wAVR: WiFi AVR ISP/PDI/uPDI Programmer.

Maven: WiFi ARM Cortex-M Debugger/Programmer

https://www.maverick-embedded.co...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Maybe this should be moved to the SAM forums then?

+1  But no-one else seems to agree with that suggestion.

 

I seem to recall that this [post in correct forum] has been suggested before for this poster.
All in this forum:

 

https://www.avrfreaks.net/forum/...

Fianawarrior wrote:

The target device is a SAMA5D44 AR processor.

 

https://www.avrfreaks.net/forum/...

Fianawarrior wrote:
SAMA5D44, 512MBytes of lovely DDR RAM ;)

 

https://www.avrfreaks.net/forum/...

Fianawarrior wrote:
EDITTED: I have 512MBytes of DDR 

 

...

 

Try:

 

  1. Home
  2. » Communities
  3. » Atmel SMART ARM-based MCUs
  4. » Forums
  5. » Tools
  6. » Compilers, Assemblers, Linkers and General Programming (ARM-related)

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Fri. Jun 7, 2019 - 12:15 PM