My MCU hangs when i jump to an address in flash memory.. (SOLVED !)

[SOFTengCOMPelec]

I had some free time and i solved the free space error. Now i get the correct size of the memory card in bytes and i get the correct size of the amount of free bytes. I made a calculation error. While looking through the header file of fatfs called ff.h and reading through the FATFS struct i found out what i did wrong. CRC functions work, now i have to write a few read write tests for the sd card and perform the tests and compare the results.

Because it is a 32 bit processor (Arm7), has that limited the SD card to a max of 2 or 4 Gb, or can it do > 4Gb ?

 

[William Gaatjes]

Because it is a 32 bit processor (Arm7), has that limited the SD card to a max of 2 or 4 Gb, or can it do > 4Gb ?

The size of the sd card is not limited to 4GB for a 32bit mcu.
The maximum size is amount of bytes /sector * sectors/cluster * amount of clusters.
The free space is is amount of bytes /sector * sectors/cluster * amount of free clusters.
The fatFS filesystem stores these values in 32 bit variables that are part of the FATFS struct, so for the time being, only the way fatfs itself is implemented is the limitation. According to a friend, the maximum sd card size is at the moment limited to 32GB.

But what does happen, i mounted a 8GB card sucesfully and my print function can only display 32bit numbers, so i got an incorrect value for the actual size and for the amount of available free space. Thus i have to write (or google for it) a (int64_t to ascii ) 64 bit itoa.

EDIT:
I forgot to mention that i previously, did al my tests with an old 16MB sd card. The problem with the 8GB card i found out today after trying it out.

 

[William Gaatjes]

I just tested it with a 1GB sdcard from my old camera, and the sd card mounts perfectly. And i can read it. Size and free space is given correctly while comparing it with the values windows provides.

 

[SOFTengCOMPelec]

The size of the sd card is not limited to 4GB for a 32bit mcu.
The maximum size is amount of bytes /sector * sectors/cluster * amount of clusters.
The free space is is amount of bytes /sector * sectors/cluster * amount of free clusters.
The fatFS filesystem stores these values in 32 bit variables that are part of the FATFS struct, so for the time being, only the way fatfs itself is implemented is the limitation. According to a friend, the maximum sd card size is at the moment limited to 32GB.

But what does happen, i mounted a 8GB card sucesfully and my print function can only display 32bit numbers, so i got an incorrect value for the actual size and for the amount of available free space. Thus i have to write (or google for it) a (int64_t to ascii ) 64 bit itoa.

EDIT:
I forgot to mention that i previously, did al my tests with an old 16MB sd card. The problem with the 8GB card i found out today after trying it out.

That's good, a limit of 32Gb allows a lot of flexibility with the SD cards.

One option, to remove the need for 64 bit itoa, would be to display the answer, in Kilobytes (1024).
Then all you would need to do, is divide the 64 bit value by 1024, then display/output the 32 bit number as usual.
That may even be a preferable method, because 64 bit numbers, are a bit too big, to be read by humans, easily.

 

[William Gaatjes]

That's good, a limit of 32Gb allows a lot of flexibility with the SD cards.

One option, to remove the need for 64 bit itoa, would be to display the answer, in Kilobytes (1024).
Then all you would need to do, is divide the 64 bit value by 1024, then display/output the 32 bit number as usual.
That may even be a preferable method, because 64 bit numbers, are a bit too big, to be read by humans, easily.

Yeah, presenting a 64 bit number is a bit to much. So i am going to limit it to 1TB. That should be enough for a few years to come. And i am going to borrow an idea from microsoft, presenting the number as a sequence of 3 digits followed by a point and another 3 digits. For example : 123.456.789.012 bytes.


I do not need a real itoa. I already have 32bit to hex converter function and a 32bit to binary function. One works with a lookup table while shifting 4 bits in a row and another which just shifts 32 bits and checks which bits are 0 or 1. So i am going to make a simplified itoa version that just does base 10 conversion.

 

[SOFTengCOMPelec]

Yeah, presenting a 64 bit number is a bit to much. So i am going to limit it to 1TB. That should be enough for a few years to come. And i am going to borrow an idea from microsoft, presenting the number as a sequence of 3 digits followed by a point and another 3 digits. For example : 123.456.789.012 bytes.


I do not need a real itoa. I already have 32bit to hex converter function and a 32bit to binary function. One works with a lookup table while shifting 4 bits in a row and another which just shifts 32 bits and checks which bits are 0 or 1. So i am going to make a simplified itoa version that just does base 10 conversion.

What I meant was that the 32 bit itoa, will work just great with the 64 bit number (up to about 4T), without needing to write any code.

As long as you shift the number 10 positions (>>) to the right (i.e. /1024), which turns it into K (Kilobytes). If you don't have a 64 bit bit shift available, it can be done in 2 goes of 32 bits.

But writing a 64 bit version of itoa (for dec only) is a good solution as well.

The 123.456.789 separators are usually used in Germany (and related countries).

The 123,456,789 separators are usually for the UK, and related countries.

, 3 digit separator is probably more commonly used, world wide than .

EDIT: In theory, Kilobytes should give just about the same resolution (consumed on disk size, actual length WOULD suffer resolution loss) as bytes (very roughly). Because the minimum sector/block size is likely to be similar to a kilobyte (roughly).
E.g. A 1 byte file would be 256 bytes, 512, 1K 2K 4K 8K etc, minimum size (on SD 'disk').

EDIT2: Your method is probably best, as the it gives the full number of bytes available.

When I'd written the original post, I was under the impression that a 64 bit itoa, was beyond what you had time to write and/or were comfortable developing, hence the original suggestions.

Sorry if I'd misunderstood. Hence me supplying a way of doing it with a 32 bit itoa.

 

[William Gaatjes]

What I meant was that the 32 bit itoa, will work just great with the 64 bit number (up to about 4T), without needing to write any code.

As long as you shift the number 10 positions (>>) to the right (i.e. /1024), which turns it into K (Kilobytes). If you don't have a 64 bit bit shift available, it can be done in 2 goes of 32 bits.

But writing a 64 bit version of itoa (for dec only) is a good solution as well.

I understand what you mean.
But for testing purposes, i really need to be sure. So for that reason i went for a 64bit itoa.

The 123.456.789 separators are usually used in Germany (and related countries).

The 123,456,789 separators are usually for the UK, and related countries.

, 3 digit separator is probably more commonly used, world wide than .

Thanks, i will make a define that will allow selection and the use of both characters.

EDIT: In theory, Kilobytes should give just about the same resolution (consumed on disk size, actual length WOULD suffer resolution loss) as bytes (very roughly). Because the minimum sector/block size is likely to be similar to a kilobyte (roughly).
E.g. A 1 byte file would be 256 bytes, 512, 1K 2K 4K 8K etc, minimum size (on SD 'disk').

EDIT2: Your method is probably best, as the it gives the full number of bytes available.

When I'd written the original post, I was under the impression that a 64 bit itoa, was beyond what you had time to write and/or were comfortable developing, hence the original suggestions.

Sorry if I'd misunderstood. Hence me supplying a way of doing it with a 32 bit itoa.

Well, i got an itoa funtion from a friend, and i stripped it down to only be able to do base 10. And i increased the types from 32 bit to 64 bit.
But when i wanted to use the % modulo and and divide / functions, i got an error. As it turns out, my linker file was not setup to support newlib libc functions.
I had to add the following :

	PROVIDE_HIDDEN (__exidx_start = .); /* Newlib support */
	ARM.exidx :
		{
		. = ALIGN (4);
		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
		. = ALIGN (4);
		} > ROM
	PROVIDE_HIDDEN (__exidx_end = .);

and

		_end = .; /* newlib support for heap functions */
		__end = _end;
		PROVIDE(end = .);

to my linker file.
So i adjusted my W-ARM program manager once again to create a correct linker file. Then i needed to make some support functions for _exit , _getpid, _kill and _sbrk. These functions are typically not needed for an embedded system without an oS. So i made a newlibsupport file with these stubs functions according to this website :

http://sourceware.org/newlib/libc.html#Stubs

EDIT:
I got lucky, because someone on the internet had the same problems.
For those reading this thread and have similar issues :

http://embdev.net/topic/282936
If you type "ld --verbose " the ld linker will generate a default linkerscript file with all options.
That is where i got the text from.

And for an excellent explanation about and why the linkerfile (for as long as it exists...)
http://www.embedded.com/design/mcus...ilding-Bare-Metal-ARM-Systems-with-GNU-Part-3
/EDIT:

And it works.
But believe it or not, while my sam7s256 with fatfsr011 has no problem reading a 8 GB card, windows 7 cannot access it or format it.
It seems to W7 that there is no sdcard inserted....
In my androidphone it used to work fine.
My controller can read it fine...
It displays all folders and some files.
According to my controller this is the size of the card :

64bit Total disk space = 7,957,774,336 bytes
64bit Free disk space = 1,451,393,024 bytes

Go figure...

 

[SOFTengCOMPelec]

And it works.
But believe it or not, while my sam7s256 with fatfsr011 has no problem reading a 8 GB card, windows 7 cannot access it or format it.
It seems to W7 that there is no sdcard inserted....
In my androidphone it used to work fine.
My controller can read it fine...
It displays all folders and some files.
According to my controller this is the size of the card :


Go figure...

There is a free program, which might work with it. For (windows or Mac) called SDformatter. It might read/detect/format it, even if windows can't.

https://www.sdcard.org/downloads/formatter_4/

(I could easily be wrong) But vaguely remember that windows is not brilliant with SD cards, and the above utility improves your chances of success.

Although technically speaking, it is sort of good that your software (using the libraries) can read/format etc it, and the android phone. It should really be working on windows, as well.

If it is only yourself who is going to be using this software, and you are happy with it, then that is fine!

But if you want others to be able to use your software, and they may need to use it with windows, directly. Then there could be more work to do.

It's quite possible that in general, your software will work, as it is, just fine with windows, and it could just be a one off problem.

 

[William Gaatjes]

Thanks, i will try that.

I just changed my W-ARM program manager once again to give support to newlib :
I changed it according to examples on the internet.
This is my by W-ARM program manager generated linker file :

/**************************************************************************
* W-ARM linker script V2.0 for SAM7 series and LPC 210x series = ARM7TDMI 
***************************************************************************/

OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")     /* output format */
OUTPUT_ARCH(arm)        /* architecture */

ENTRY(_start)  /*First executable instruction can be found here */

MEMORY {    /* memory map of ARM MCU */
ROM (rx)  : ORIGIN = 0x00104000, LENGTH = 0x3C000
RAM (rwx) : ORIGIN = 0x00200000, LENGTH = 0xF000
}

/* The sizes of the stacks used by the application. */
C_STACK_SIZE = 16384;
IRQ_STACK_SIZE = 80;
FIQ_STACK_SIZE = 36;
SVC_STACK_SIZE = 512;
ABT_STACK_SIZE = 12;
UND_STACK_SIZE = 0;


SECTIONS
{
	.reset :	/* Startup code (ROM vectors and reset handler) */ 
		{ 
		*startup.o (.text)
		. = ALIGN(4);
		} >ROM

	.fastcode :	/* All the instruction code in ROM copied to RAM are stored in ROM here */
		{
		__fastcode_load = LOADADDR (.fastcode);
		__fastcode_start = .;
		*isr_asm.o (.text)	/* RAM vectors and assembler parts of the interrupt routines are placed in the isr_asm.s file*/
		. = ALIGN (4);
		*isr.o (.text)			/* All interrupt service routine code is placed in the isr.c file*/
		. = ALIGN (4);
		*fastexec.o (.text)	/* All fast executing code is placed in the fastexec.c file */
		. = ALIGN (4);
		*(.glue_7t) *(.glue_7) /* ARM / Thumb interworking code. */
		. = ALIGN (4);
		__fastcode_end = .;
		} >RAM AT>ROM

	.text :	/* All the instruction code not copied to RAM are stored in ROM here */
		{
		*fattime.o (.text)
		*ff.o (.text)
		*inithardware.o (.text)
		*isr_ctrl.o (.text)
		*main.o (.text)
		*menu.o (.text)
		*mmc_sd.o (.text)
		*newlib_support.o (.text)
		*os_functions.o (.text)
		*sci.o (.text)
		*semi_stdio.o (.text)
		*string.o (.text)
		*timer.o (.text)
		. = ALIGN (4);
		} >ROM

	PROVIDE_HIDDEN (__exidx_start = .); /* Newlib support */
	ARM.exidx :
		{
		. = ALIGN (4);
		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
		. = ALIGN (4);
		} > ROM
	PROVIDE_HIDDEN (__exidx_end = .);

	.data :	/* All global and static variables are stored here */
		{
		. = ALIGN (4);
		__data_load = LOADADDR (.data);
		__data_start = .;
		*(.data)
		. = ALIGN (4);
		__data_end = .;
		} >RAM AT>ROM

	.bss :	 /* Static variables initialized to 0x00*/
		{
		. = ALIGN (4);
		__bss_start = . ;
		*(.bss). = ALIGN (4);
		__bss_end = .;
		} >RAM

	.stack :	 /* All the stacks */
		{
		. = ALIGN (4);
		__stack_start = .;

		. += IRQ_STACK_SIZE;
		. = ALIGN (4);
		__irq_stack_top = .;

		. += FIQ_STACK_SIZE;
		. = ALIGN (4);
		__fiq_stack_top = .;

		. += SVC_STACK_SIZE;
		. = ALIGN (4);
		__svc_stack_top = .;

		. += ABT_STACK_SIZE;
		. = ALIGN (4);
		__abt_stack_top = .;

		. += UND_STACK_SIZE;
		. = ALIGN (4);
		__und_stack_top = .;

		. += C_STACK_SIZE;
		. = ALIGN (4);
		__c_stack_top = .;

		__stack_end = .;
		. += 4;
		_end = .;
		} >RAM

		/* heap */
		PROVIDE(_HEAP_START = _end);
		/* end of the heap */
		PROVIDE (_HEAP_END = ALIGN(ORIGIN(RAM) + (LENGTH(RAM)-1)));
}
/*** EOF ***/

I have a function callede _sbrk to support malloc.

I have done a few tests to see if it works and it seems malloc uses some free space of the heap for bookkeeping.

// linker sets heap start and end
	extern uint32_t  _HEAP_START;
	extern uint32_t  _HEAP_END;
	static caddr_t heap = NULL;

// low level bulk memory allocator - used by malloc
caddr_t _sbrk (uint32_t increment)
{
	caddr_t prevheap;

	PrintString("_HEAP_START : %h \r\n",(uint32_t)_HEAP_START);	
	PrintString("&_HEAP_START : %h \r\n",(uint32_t)&_HEAP_START);	
//	PrintString("_HEAP_END : %h \r\n",(uint32_t)_HEAP_END);	 Generates an abort. 
	PrintString("&_HEAP_END : %h \r\n",(uint32_t)&_HEAP_END);	

  if (heap == NULL) 
	{
		// first allocation
    heap = (caddr_t)&_HEAP_START;
	}

	prevheap = heap;

	if (((uint32_t)heap + (uint32_t)increment) >= (uint32_t)&_HEAP_END) 
	{
		return NULL;
	}
	heap += increment;

	PrintString("heap : %h \r\n",(uint32_t)heap);	
	PrintString("prevheap : %h \r\n",(uint32_t)prevheap);	

  return (caddr_t) prevheap;    
}

It seems that when comparing to my map file tht it all seems to work.
i have some debug code enabled in side _sbrk to see what haapens to the heap and it seems to all work out.

 

[William Gaatjes]

It tried the sdcard formatting utility but it also could not recognize the card.
After trying with a different card reader, there is no blame to W7. It was my card reader that does not support the 8GB card. my old 16MB card is an MMC card and the 1GB card is an SD Card. Probably is the 8GB an SDXC. (I still have to read up on all those differences.) It was my card reader. :$

 

[SOFTengCOMPelec]

It tried the sdcard formatting utility but it also could not recognize the card.
After trying with a different card reader, there is no blame to W7. It was my card reader that does not support the 8GB card. my old 16MB card is an MMC card and the 1GB card is an SD Card. Probably is the 8GB an SDXC. (I still have to read up on all those differences.) It was my card reader. :$

I'm glad you got that sorted out, and it was NOTHING to do with your new software, you are writing.
I guess an SD card, would also allow a huge amount of debug (Printf etc) information to be written to it. Even for a tiny embedded system.

 

[William Gaatjes]

I'm glad you got that sorted out, and it was NOTHING to do with your new software, you are writing.
I guess an SD card, would also allow a huge amount of debug (Printf etc) information to be written to it. Even for a tiny embedded system.

Yeah, Imagine using 16GB to log data. That would be a lot of data.
Personally, i want to put wave sounds in the wav format onto the sd card and play them randomly as part of some robotic gimmick i am making out of a singing trout.
I bought a few and took them apart because the sound is awful. But the mechanics is fun.

An original singing trout.
https://www.youtube.com/watch?v=TuaoJUB7Xqc

The I2S interface of the sam7s allows for direct connection to a I2S dac.
And since the sam7s has dma for both the SPI (sdcard) and for the I2S, playing a sound is very easy without any cpu overhead. The only thing that worries me is how the data is stored on the sd card and stored in ram inside the sam7s. If that is not in the correct endian format and i cannot correct that by setting the I2S to lsb or msb first, i will have to convert the wave files into a proper format first on the pc before storing the sound files on the sd card. But that is not a real problem.

I want to use the goertzel algorithm to determine specific tones and drive the motors from the singing trout accordingly.
Since the ADC (for sound detection)also works with dma, the cpu has all the time in the world to perform signal analysis. All pheriperals can be setup to use dma. So even a good ol' ARM7TDMI can shine and show its muscles.

I will add a few more tricks to it to make it more alive and when i have finished that, i can start with another project where i will also be using a sam4s together with a sam7s.

 

[William Gaatjes]

A minute of googling solved my confusion about the sd card standards.
I have an mmc card, an sd card and an sdhc card, not an sdxc card.

For readers interested, here are some links providing information :
https://www.sdcard.org/developers/overview/capacity/

https://www.sdcard.org/consumers/choices/

https://www.sdcard.org/downloads/pls/simplified_specs/

sdcard specifications 2013 :
https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

 

[SOFTengCOMPelec]

Yeah, Imagine using 16GB to log data. That would be a lot of data.
Personally, i want to put wave sounds in the wav format onto the sd card and play them randomly as part of some robotic gimmick i am making out of a singing trout.
I bought a few and took them apart because the sound is awful. But the mechanics is fun.

An original singing trout.
https://www.youtube.com/watch?v=TuaoJUB7Xqc

The I2S interface of the sam7s allows for direct connection to a I2S dac.
And since the sam7s has dma for both the SPI (sdcard) and for the I2S, playing a sound is very easy without any cpu overhead. The only thing that worries me is how the data is stored on the sd card and stored in ram inside the sam7s. If that is not in the correct endian format and i cannot correct that by setting the I2S to lsb or msb first, i will have to convert the wave files into a proper format first on the pc before storing the sound files on the sd card. But that is not a real problem.

I want to use the goertzel algorithm to determine specific tones and drive the motors from the singing trout accordingly.
Since the ADC (for sound detection)also works with dma, the cpu has all the time in the world to perform signal analysis. All pheriperals can be setup to use dma. So even a good ol' ARM7TDMI can shine and show its muscles.

I will add a few more tricks to it to make it more alive and when i have finished that, i can start with another project where i will also be using a sam4s together with a sam7s.

That sounds like a fun project!

The singing trouts, have brought back, somewhat BAD memories. Thanks!

They were fun, for the first 10 seconds, and maybe for longer than that. But they soon can get very tiring.

They were something you would impulse buy, and then after a few uses, put away in a cupboard, for some future, rainy day. Which never arrives.

If you are handy at electronics and computing/software, it is one way of cheaply and quickly, getting a robot like mechanism, going.

Don't worry, I'm NOT going to close this post, with a silly pun.

Otherwise you would feed me fish (trout) and chips (Arm7), while continually playing the same music, again, and again.

You could also make the system .wav to the user, with its Arm(7).

 

[William Gaatjes]

It is a fun project and since i use all new hardware and software techniques i never used before, it is going to be an excellent learning moment.
I finally had time to do the read tests with crc checks and the read write tests with crc checks. And it all checks out.
I read in a file of 32152 bytes into memory and and then wrote it back to the sdcard and it works. After comparing the original with the copied file by use of Winmerge, i can confirm that all works.

I can now start with making a small experimental prototyping pcb with the I2S dac on it. And then i can try to read in a wave file and produce some music and spoke voice.

But i will make a new thread with schematic and specifics about that after i have gotten some sound out of it.