Atmel start Samd21j16b stuck at Reset_Handler(), _lib_init_array(), Dummy_Handler() when using LinkedList. HELP PLEASE!

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

I'm trying to port arduino ModbusSlave lib(https://github.com/lucasso/Modbu...), for generic use with samd.

 

I'm no expert in compiling and manual memory aloccation, so please bear with me.

 

Project is attached.

 

i'm using atmel ice for programming and debugging.

The main code is simple, and it isn't even using the functions and classes that cause the problem, they just are in the project folder and linked in directories compiler. I'm compiling C++ using this method: https://microchipsupport.force.c...

It compile without a problem, but when i run the code it get stuck at reset_handler(), like there was a interrupt without a handler. After tracking the problem, it appears to be something related to linked lists.

This are the functions that cause the problem, if i comment them all, it works as it should.(obviously wouldn't be able to use modbus slave, but i'm aren't using it at the moment, the problem is caused just for being in the project directories)

 


 

 

The problem seems to be similar to the one described here: https://www.avrfreaks.net/forum/...

but i couldn't use this solution, as atmel had already resolve it, and wasn't the exact same problem.

The code jumps from _libc_init_array() to dummy_handler(void);

 

here are logs of debugging:

 

any help would be appreciated wink
 

Attachment(s): 

This topic has a solution.
Last Edited: Wed. Jun 29, 2022 - 06:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

after further investigation, the problem comes with the new statement that uses dinamic memory allocation, is there a problem in using dinamic memory allocation on SAMD proccessors?

Last Edited: Wed. Jun 1, 2022 - 01:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

so i change the new statement to malloc, and it doesn't get stuck where it shouldn't without calliing functions. It would be nice if some1 can tell if new is not supported, is a bug or something else is happening here.

 

 

Now i have another problem, in LinkedList, the virtual statement are causing conflict.

 

 

 

After some trials, i noticed that the problem is when you construct a class that has a virtual statement with a pointer. As you can see in the image below, when there is no virtual statement, test3 is created with every member of the class. If there is at least one virtual statement, test3 is created with no other members attached, so later when yuo try to call a fucntion, it goes to the dummy handler, as the function doesn't exist, but was compilated.

 

 

 

 

I tried removing the virtual statements, but got other errors in its place that i can't resolve for the moment. If some1 can help with this, i would appreciate it. I want to know why the virtual statement is having problem, this is a problem with c++ or a problem with atmel compiler?

 

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

For the original problem I tested your project with a SAMD21J18 and it runs fine. I added a LinkedList instance allocation also.

The problem is the amount of SRAM used by the C++ runtime. If you put a break point inside _sbrk (utils_syscalls.c) you will notice two massive allocations (2552 + 3328 bytes). You can see the result here:

 

 

Look at the address of myList, it's outside the available SRAM on a SAMD21J16 (it has 8K so the SRAM space ends at 0x20002000). 
To have more free SRAM:

  • Change the project linker options to "Use size optimized library" (in project settings Toolchain ARM/GNU Linker General).
  • Reduce the stack size (looks like 2K in samd21j16b_flash.ld).

About your last post and problems with virtual statements: you have not allocated the object (and not used it so it's optimized out).
/Lars

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

 

Lajon, thank you for your help and your reply.

 

For the last post, i have worked a litle bit more, changing new for malloc, and i didn't get the problem with memory aloccation (don't know why new gives the problem). After testing i got this.

where test3 is in a usable memory space.

The problem is when i run test3->size() it jumps to Dummy_handler in startup_samd21.c

After trials and errors i discover that if i remove virtual from size, it works, if i don't remove it, it doesn't work. The problem is for the implementation it needs to be virtual, for now i'm using a non virtual implementation that only works for my modbus slave lib, but it means that if i want to use lists in other projects i have to adapt it every time.

Could the virtual part be allocated otside the memory availabe? if it's like that how can i check it?

 

I attached the project with modifications.

 

 

Attachment(s): 

Last Edited: Tue. Jun 7, 2022 - 05:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like you have not done this:
 

  • Change the project linker options to "Use size optimized library" (in project settings Toolchain ARM/GNU Linker General).

 

Do that and new should be ok use. 

You can't allocate objects with malloc by just casting the pointer. The constructor will not run so the object is not properly setup.

/Lars

 

 

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

 

Lajon wrote:

Looks like you have not done this:
 

  • Change the project linker options to "Use size optimized library" (in project settings Toolchain ARM/GNU Linker General).

 

Do that and new should be ok use. 

You can't allocate objects with malloc by just casting the pointer. The constructor will not run so the object is not properly setup.

/Lars

 

 

 

I did this, and it worked to some point. The problem that it broke the sprintf function, i can't risk having other functionalities compromised.

if i do that to linker it gives garbage. if i change temporary size from 12+sizeof to 20+sizeof, cont is always 0, so the how sprintf works depends on size of previous array, that seems like someproblem woth memory segments where the varaibles are created.

 

i think i'll just have to resign myself to not use linked lists with this chip, as it doesn't have enough memory for it.

 

Last Edited: Wed. Jun 8, 2022 - 09:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Post #5 here:

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

might help to restore floating point printf (and sprintf) when using the size optimized library.

/Lars

 

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

hi, i have retake this part of my project recently, and i still have some problems, i have implemented all the things suggested here, it helped a lot on other libraries for the project, but still have the problem with virtual statement. whatever i do it keeps going to dummy handler.

 

  Assembly code, where it goes to dummy after instrtuction 0000375C.  r4 = 2000048c

	for(int i = 0; i < words->size(); i++)
0000375A   movs	r4, #0		 
0000375C   b	#0		 
--- No source file -------------------------------------------------------------
0000375E   adds	r4, #1		 
00003760   ldr	r0, [r5, #24]		 
00003762   ldr	r3, [r0]		 
00003764   ldr	r3, [r3, #8]		 
00003766   blx	r3		 
00003768   cmp	r4, r0		 
0000376A   bge	#28		 
0000376C   ldr	r0, [r5, #24]		 
0000376E   ldr	r3, [r0]		 
00003770   ldr	r3, [r3, #40]		 
00003772   movs	r1, r4		 
00003774   blx	r3		 
00003776   cmp	r0, #0		 
00003778   beq	#-30		 
0000377A   ldrh	r3, [r0]		 
0000377C   cmp	r6, r3		 
0000377E   blt	#-36		 
00003780   ldrb	r1, [r0, #2]		 
00003782   adds	r3, r3, r1		 
00003784   cmp	r6, r3		 
00003786   bge	#-44		 
00003788   b	#0		 
0000378A   movs	r0, #0		 
0000378C   pop	{r4, r5, r6, pc}		 
0000378E   movs	r0, r0		 
00003790   push	{r4, r5, r6, lr}		 
00003792   movs	r4, r0		 

 

function where it goes to dummy: words->size()

ModbusRTUSlaveWordAddress* ModbusRTUSlave::getWordAddress(u16 Addr)
{
	for(int i = 0; i < words->size(); i++)
	{
		ModbusRTUSlaveWordAddress* a = words->get(i);

		if(a!=NULL && Addr >= a->addr && Addr < a->addr + a->len)
		  {
			//"FOUND"
			return a;
		  }
	}
	//"NOT FOUND"
	return nullptr;
}

 

virtual function that cuase the problem. (all virtual functions cause this problem)

Returns current size of LinkedList
	*/
	virtual int size();

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i manage to solve this with this

 

Lajon wrote:

 

Look at the address of myList, it's outside the available SRAM on a SAMD21J16 (it has 8K so the SRAM space ends at 0x20002000). 
To have more free SRAM:

  • Change the project linker options to "Use size optimized library" (in project settings Toolchain ARM/GNU Linker General).
  • Reduce the stack size (looks like 2K in samd21j16b_flash.ld).

About your last post and problems with virtual statements: you have not allocated the object (and not used it so it's optimized out).
/Lars

 

plus this:

 

Lajon wrote:

Post #5 here:

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

might help to restore floating point printf (and sprintf) when using the size optimized library.

/Lars

 

couldn't resolved the virtual statement problem, i worked arround changing the linked list from templeate t to 2 different linked lists classes with specif constructors (and a lot of errors that  i had to resolve due to this port) for the 2 classes that modbus slave library uses with linked lists,