Code stuck in Reset_Handler after Atmel Studio upgrade to 7.0.1417

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

Hello,

We have been developing the code on Atmel Studio 7.0.1188 and then we updated to 7.0.1417 (Win10 64bit). The problem is that our code was running fine on ATSAME70Q21 (384kB RAM, 2MB flash), after the upgrade the code is stuck in Reset_Handler. We've been using the standard linker file provided by Softpack ( same70_flash.ld_.txt) and now the following variables are 0x0000000 instead of some values from RAM (0x020400000): _etext, _srelocate, _erelocate, _szero, _ezero, but _sfixed= 0x20432020.

Output result:

        arm-none-eabi-size.exe ucs.elf
           text       data        bss        dec        hex    filename
         732568       3576     332320    1068464     104db0    ucs.elf

This is the same result from compiling the previous version, also the map files seem very similar, they show the .heap, .stack, .bss segments having close values inside RAM space. We have upgraded and downgraded a few times, tried on different workstations and the problem follows the upgraded version. Could this be a bug in the linker?

Best regards,

David.

Attachment(s): 

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

Hello,

I have a similar problem on my ATSAME70Q19. I am using Atmel Studio 7.0.1417 and since updating my application stucks in the Reset_Handler(void) in startup_same70.c

I also checked the gcc linker file but I cannot find any differences.

I also checked the GPNVMBITS and they are 0x82. Security Bit is not set. I found out that in the reset handler the function __libc_init_array() produces the problem. After

commenting out that function I reach main() but doing so, suddenly sysclk_init() makes problems.

Something with the memory mapping seems to be wrong. I also tried to build a brand new project but I still have the same problem.

I thought that I found a solution by inserting the following lines:

 

    SCB->VTOR = ((uint32_t) pSrc & SCB_VTOR_TBLOFF_Msk);

#if __FPU_USED
	fpu_enable();
#endif


//		EFC->EEFC_FMR = 0x00000000;
//		EFC->EEFC_FMR |= EEFC_FMR_CLOE; 
		
		/* TCM Configuration */
//		EFC->EEFC_FCR = (EEFC_FCR_FKEY_PASSWD | EEFC_FCR_FCMD_CGPB | EEFC_FCR_FARG(8));
//		EFC->EEFC_FCR = (EEFC_FCR_FKEY_PASSWD | EEFC_FCR_FCMD_CGPB | EEFC_FCR_FARG(7));
				
//		__DSB();
//		__ISB();
//		SCB->ITCMCR &= ~(uint32_t)(1UL);
//		SCB->DTCMCR &= ~(uint32_t)SCB_DTCMCR_EN_Msk;
//		__DSB();
//		__ISB();
		
        /* Initialize the C library */
        __libc_init_array();

 

Here I set the GPNVMBITS to 0x02. If I do so I reach main() and I have no problems with sysclk_init(). Unfortunatelly the application crashes after a few seconds and

ends up in the dummy_handler() because of hard fault error.

I hope somebody can help me/us with this problem.

 

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

For me doesn't even reaches_libc_init_array, it gets stuck in the first for loop initialising relocate segment because _etext and _srelocate are not valid. GPNVMBITS is set to 0x02.

void Reset_Handler(void)
{
	uint32_t *pSrc, *pDest;

	/* Initialize the relocate segment */
	pSrc = &_etext;
	pDest = &_srelocate;

	if (pSrc != pDest) {
		for (; pDest < &_erelocate;)
			*pDest++ = *pSrc++;
	}

	/* Clear the zero segment */
	for (pDest = &_szero; pDest < &_ezero;)
		*pDest++ = 0;

	/* Set the vector table base address */
	pSrc = (uint32_t *) & _sfixed;
	SCB->VTOR = ((uint32_t) pSrc & SCB_VTOR_TBLOFF_Msk);

 

 

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

I've seen something similar to your behaviour even on previous version, at some point had ASF running but when I added C++ code, it would crash as you described. I think there were some compiler flags that I added but when I reverted to default project flags that you get when creating a new project, started working again. Also, it could be that you need to link to link your program to the correct library designed for Cortex Thumb instructions, might have changed in new version of AS7.

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

We have been having a similar problem:  I found the  post below  which seems to be related   :

 

It looks like there is a problem with the SAM-ICE not initializing all the control registers properly.

 

http://forum.segger.com/index.ph...

 

the variables are as follow:

Source code

1
2
3
&_erelocate = 0x200715cc
&_srelocate = 0x20070000
&_etext   	= 0x9773c

this seems all reasonable. But

Source code

1
_pDest = 0x0

This can not happen with this code. Interrupts are turned off at this point. And it only happens if the debugger is connected. So my guess is that the debugger somehow messes with the variable?

 

--------------------------

 

Also I have observed that an Uninstall of Atmel Studio 7.0.1147 does NOT remove the SAM-ICE and other

components that were installed.   I am going to try removing everything related to J-link, SAM-ICE and AS7

and try reinstalling 7.0.1188.  Also check the version of the SAM-ICE flash and related DLLs.  It could be that it is not possible to downgrade

the SAM-ICE flash version.

 

 

 

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

@Mike-w: for me is stuck every time in that loop, even if I disconnect the debugger and reboot the board without it connected. Once I attach the debugger and use Debug->Attach to Target, I can see the breakpoint in same location. Never observed the behaviour you described in previous version (v5.3.1) of the compiler.

 

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

I ran into this problem after some updates today as well.

 

 

mike-w wrote:

 

Also I have observed that an Uninstall of Atmel Studio 7.0.1147 does NOT remove the SAM-ICE and other

components that were installed.   I am going to try removing everything related to J-link, SAM-ICE and AS7

and try reinstalling 7.0.1188.  Also check the version of the SAM-ICE flash and related DLLs.  It could be that it is not possible to downgrade

the SAM-ICE flash version.

 

 

The SAM-ICE is just a branded J-LINK that's locked to Atmel parts. It's basically a completely separate application/tool, they interface via GDB. Atmel studio installs the j-link tools automatically, but the version it installs is rather old. 

 

Updating is pretty straight forward, but you have to do a little hand-holding. Basically, installing a new version doesn't remove the older version, so you basically have to install the new jlink package (6.14h at the moment), uninstall 6.12, and then use the j-link configurator to update the firmware on the debug probe.

 

------

 

Unfortunately, updating the j-link tools doesn't actually seem to fix the problem (_etext is still 0x0 when I look at it in the debugger, and I get crashes), but it's something.

Last Edited: Wed. May 24, 2017 - 12:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm also seeing bizarre and seemingly related problems with my app after upgrading from AS 7 1188 to 1417.

 

I get malloc returning 0 even though it has sufficient memory available, exceptions being thrown, and if those don't get it, I see Usage faults such as "Undefined instruction". In summary, the program is not stable and invariably fails within a few seconds of starting, for various and seemingly inexplicable reasons. Often the memory failures occur within __libc_init_array() or another function using malloc soon after program start.

 

I was having no such problems before the upgrade. I have also tried to use the older toolchain that came with 1188 (with GCC 5.3.1), from within build 1417. This seems to have no effect, which is surprising because I expected the issue to be related to the new version of libc.

 

In debugging all of this, I have modified the _srbk() function that feeds malloc with memory, and overridden ::operator new() to use FreeRTOS' threadsafe malloc once the FreeRTOS heap is initialized. This helps me to debug it, but is seemingly unnecessary and reveals no smoking guns.

 

Note also that I am not using ICE but rather EDBG, and it seems to occur even when I'm not actively debugging.

 

Very frustrating. Anyone come up with any leads?

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

Same here, after upgrade of AS7, toolset and ASF my application hangs in the relocate segment for loop. It appears that the source and destination pointers are not initialized properly as shown in this sceenshot:

Downgrade of toolchain to 5.3.1 doesn't help. But more simple applications seem to work well, see this screenshot here:

So I assume that something goes wrong in calculation of etext and srelocate etc. Any idea what to do ? Thanks.

SAME newbie

Last Edited: Thu. Jun 22, 2017 - 06:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i had same problem. it is the gpnvm bits (8:7) that seem to be modified , by the ice or debugger during downlaod,  so that the full sram is not available and some is allocated to the tcm sections. so when the processor boots the stack is set automatically and if > 128k (in my case) then you see the problems you are having (stack pointing to no valid sram). i did this to startup_same70 and problem is sorted, hope this helps you:-

 

you can check if that is the problem with the ice by going to memory iram region and try modify the data manually, in my case 0x41ffff was ok but from 0x420000 i couldn't modify

 

void Reset_Handler(void)
{
        uint32_t *pSrc, *pDest;

 

     EFC->EEFC_FCR = (EEFC_FCR_FKEY_PASSWD | EEFC_FCR_FCMD_GGPB);

    uint32_t ulEEFC_bits = EFC->EEFC_FRR;
  
    if ((ulEEFC_bits & 0x180) != 0x0)
    {
        EFC->EEFC_FCR = (EEFC_FCR_FKEY_PASSWD | EEFC_FCR_FCMD_CGPB 
                    | EEFC_FCR_FARG(8));
        EFC->EEFC_FCR = (EEFC_FCR_FKEY_PASSWD | EEFC_FCR_FCMD_CGPB 
                    | EEFC_FCR_FARG(7));
        // Trigger Reset
        RSTC->RSTC_CR = RSTC_CR_KEY_PASSWD | RSTC_CR_PROCRST;    
    }

howien

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

howien12 wrote:

i had same problem. it is the gpnvm bits (8:7) that seem to be modified , by the ice or debugger during download,  so that the full sram is not available and some is allocated to the tcm sections. so when the processor boots the stack is set automatically and if > 128k (in my case) then you see the problems you are having (stack pointing to no valid sram). i did this to startup_same70 and problem is sorted, hope this helps you:-

 

Finally, that does make some sense. Probably it's the popup window that occurs the first time you run your app under the new atmel studio and which that flashes something onto the device. In my case it asked me to flash from version 1.f I believe to 2.1 the first time I ran -- I think this was called the "device pack" (all of this is from vague memory so could be wrong on the details). That would explain why the issues would continue even after reverting to the old toolchain (and even people saying they re-installed the older atmel studio to no effect).

 

My only question is this whether you think it's necessary to then use the following code after setting EEFC_FCR, as seen in an earlier post:

 

__DSB();
__ISB();
SCB->ITCMCR &= ~(uint32_t)(1UL);
SCB->DTCMCR &= ~(uint32_t)SCB_DTCMCR_EN_Msk;
__DSB();
__ISB();

 

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

that is part of the init() code, if you are not using any tcm memory regions (as i am currently) then i don't see any issue with it.

 

i commented the fcr changes out but left the tcm_disable(). if you also use the tools->deviceprogramming tool, it used to show the gpnvm bits as 0x82 .... strange!! that only shows bits 0..7 , bit 8 is a valid bit so in my opion is should display a 16bit value ... 0x??82

 

 

    /* TCM Configuration */
//    EFC->EEFC_FCR = (EEFC_FCR_FKEY_PASSWD | EEFC_FCR_FCMD_CGPB 
//                    | EEFC_FCR_FARG(8));
//    EFC->EEFC_FCR = (EEFC_FCR_FKEY_PASSWD | EEFC_FCR_FCMD_CGPB 
//                    | EEFC_FCR_FARG(7));
    
    tcm_disable();

 

howien

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

I would add one other thing that seems to have affected me.

 

_sbrk() is defined in ASF/sam/utils/syscalls/gcc/syscalls.c. This provides the memory blocks from which std::malloc() allocates memory.

 

Before this upgrade to Atmel Studio, I had never looked at this function, and everything seemed to work fine. I had a heap section in the linker script, which a big chunk of remaining memory from after the stack to the end of usable memory (for me that meant until the beginning of the section for which caching is disabled). Presumably, the HEAP section is where malloc would allocate memory, obviously, right? Well, I thought that was the case, as I never had to think about it and everything worked. But somehow after the upgrade. Possibly, the libc provided it's own version of _sbrk() or _sbrk_r() that overrode this function, and perhaps it was never used. Or perhaps the libc is just enough bigger to make the heap section extend to nearly the end of memory. In any case, the _sbrk provided in the above file DOESN'T use the HEAP section for the default linker scripts provided with the ASF apps I've tried. Instead it begins allocating memory at the _end symbol, up until the __ram_end__ symbol. For me, and likely most people, _end comes at the end of the HEAP.

 

This meant malloc had little to no memory to work with and failed. The solution, as also discussed here, is to change _sbrk() to put the malloc heap between _sheap and _eheap.

Last Edited: Fri. Jun 23, 2017 - 11:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so is your code running now? 

howien

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

howien12 wrote:

so is your code running now? 

 

Yes, it finally seems to be working again, although I feel as if on a knife's edge after the last week. Who knows what else is going to suddenly stop working. An ASF upgrade also failed completely for me, and some of my debugging efforts seemed to compound the problems. Plus SDRAM causing random bus faults, which predates the upgrade. Anyhow, yes it seems to be working at the moment, thank goodness.

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

The good news is that my app is booting again, the bad news is I don't know why.

 

First I modified the reset handler in order to check and correct the gpnvm bits which seem to mess up the Memory configuration when programming and debugging my huge application.

Stepping thru the code I can see that bit 8+7 are set to "1" in the EFC Register but nevertheless the code does not recognize this:

 

 

Next screenshot shows that he debugger shows the expected value in the FRR register but loading the variable with the FRR Register content seems not to work and so the reset of the bits is not done nor the processor reset:

 

 

The source and destination pointers are not initialized properly and the program hangs up in the following loop. 

 

As stated in my previous post I observed that a small application with ca. 30kB Flash, 9436 Bytes Ram does boot without problems. Therefore I linked my big application (1292276 Bytes Flash, 378472 Bytes Ram) to address 0x420000 and flashed it. The I wrote a bootloader for address 0x400000 which execs the huge application at 0x420000 and now the pointers in the reset_handler are initialized properly and everything seems to work as usual. Here is the code snipped from the bootloader:

static void start_application(uint32_t APP_START_ADDRESS)
{
 uint32_t app_start_address;

 /* Rebase the Stack Pointer */
 __set_MSP(*(uint32_t *) APP_START_ADDRESS);

 /* Rebase the vector table base address */
 SCB->VTOR = ((uint32_t) APP_START_ADDRESS & SCB_VTOR_TBLOFF_Msk);

 /* Load the Reset Handler address of the application */
 app_start_address = *(uint32_t *)(APP_START_ADDRESS + 4);

 /* Jump to application Reset Handler in the application */
 asm("bx %0"::"r"(app_start_address));
}

Once the bootloader is flashed I can debug the main application as usual. Here is the sceenshot with the correct intializiation of the source and destination pointers.

Note that the variable uIEEFC_bits still does not reflect the Status of the GPNVM bits what is quite strange to me.

 

 

 

 

SAME newbie

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

BTW: According to the E70 Manual the FRDY bit shall be checked after a EFC command is released and before the FRR Status is read. Maybe this is a Timing Problem causing the invalid value here when reading the FRR register into a variable ?

SAME newbie

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

I think I found the Problem. The code for testing the GPNVM variables does fail because these variables are automatic and therefore in the stack which is obviously not accessible. Due to the linker configuration the stack is in SRAM > 128kB but at the time of the first boot the SRAM is configured to only 128kB. If I Change the variables in the posted code to static These are in SRAM < 128kB and therefore accessible. Now in the patch the SRAM is configured to 386kB if necessary and reboot. Look good for me.

Again a screenshot FYI. The question remains why the SRAM memory configuration is changed to 128kB in the Atmel Studio update.

 

SAME newbie

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

regjoe:

 

Wow. Thank you. Thank you, thank you. I had two boards with locked up SAMS70 chips and this fixed the issue. Very grateful.

 

- ndb

 

---------------------------
www.metreideas.com
www.foxonix.com

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

Hi folks!

 

Exactly the same here. I've ported a working project to another PCB and I used an E70N20 instead of an S70N20 but everything was the same. The project was working, until I wanted to use the code running from Flash. To check the problem, debug... but the peripheral registers data were absolutely bad. Okay, taking a big breath and update AS 7. (I would never do it else.) And there is the result that was present after each AS 7 update: the project is not working anymore.

 

I made the same conclusions about the TCM memory configuration and GPNVM bits. I can't set GPNVM bits, always reading back 0x82 and memory cfg. is 128k+128k TCM + 128k SRAM, and the program fails due to the stack address, where is no SRAM yet.

 

I will read carefully this thread how to eliminate AS 7's and/or Atmel-ICE's "new feature"... Why do we have to always solve problems after an update? Accessing an MCU with a tool isn't that hard to implement. Besides, some headers also change time by time and I have to modify them or my code all the time... it's a shame.

 

Bests,

Zoltan

 

Edit: meanwhile... my old projects are not running anymore as well (S70). Thanks to the accidental(?) GPNVM bit change feature of the newest AS7, I am unable to develop the code from SRAM, which would be much faster and save the flash.

Now I am going to erase AS7 and all the drivers of tools and everything and try to install an old one. This is my last try before having this bug fixed and new ones intruduced in the next release of AS7 or Atmel-ICE firmware.

Edit #2: and old AS7 doesn't disturb the GPNVM bits but it's unable to step even an instruction when stopped at a breakpoint. Then additionally throws an exception and restarts every time (AS7). Nice, now I am absolutely unable to develop any of my projects. (Tried an intermediate version too, but that one can't start the backend agent so it is more unusable than the others. :D )

Last Edited: Tue. Aug 1, 2017 - 12:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a newb to SAM processors, and I'm trying to use Atmel Studio 7.1417 with both an XPlained E70 board and with my own custom board with an S70N19 on it.

In a nutshell, I can upload code to either board (using an ATmelICE in SWD mode), but the code doesn't seem to start. The debugger makes all the noises like it's working, but it never hits a breakpoint and, while I can pause the code, the code never looks like it's running at anything like a reasonable address, and the code looks like garbage.

Is there a summary as to what I have to do to my projects (created by Atmel Start) to get them to be functional?

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

 

I think I figured it out.

The above code snippet is very helpful. The HTML editor here is terrible. I was going to paste the actual code in as text so folks could copy it out more easily, but that doesn't seem possible, so instead, I've put it on pastebin.

But that snippet by itself isn't enough. In addition, I had to go into the Tool menu of... I don't know what that window is called. It's named the same as the project. But anyway, it's where you pick the programmer and whether it's SWD or JTAG. There's a menu item there to select "boot from ROM" or "boot from Flash" but that doesn't seem to work. Instead, manually setting the GPNVM byte to 0x02 seems to do the right thing.

When you do that (without the snippet addition), it gets as far as the library initialization before that fails. The code snippet to force the GPNVM 0x180 bits to zero also seems necessary.

Ugh.

Last Edited: Thu. Sep 21, 2017 - 05:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Joe, that code also helped me a lot.

I was wondering, why do you need to store EEFC_FSR into static? Instead of having:

do{

//wait for cmd ready bit

}while ((EFC->EEFC_FSR & EEFC_FSR_FRDY) != EEFC_FSR_FRDY);

 

Same with condition, instead of storing EEFC_FRR into static, just:

if ((EFC->EEFC_FRR & 0x180) != 0x0) ...

 

Maybe there still be a possibility based on how large is your program that ulStatus_bits and ulGPNVM_bits are moved into high area of SRAM?

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

My guess is that by allocating storage for those values you can examine them in the debugger.

 

I asked Microchip about all this, btw. They say that the GPNVM bugs in Atmel Studio will be fixed in the next release.

Last Edited: Thu. Sep 21, 2017 - 05:34 PM