Monday, December 11th 2017, 10:13am UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

gpontis

Beginner

Date of registration: Dec 18th 2007

Posts: 44

Location: California

1

Friday, October 13th 2017, 3:25am

Getting started prob with SES, M7 project

I am trying to get familiar with SES by trying some of the demo programs. This is on a custom board with Atmel SAME70 microcontroller. I believe that the hardware is OK since I can program and run code and step in the debugger, via J-Link. However, all the demos blow up very early. For example, the hello world program gets a little ways into vsnprintf, then goes to the hard fault handler. It is usage fault, invalid state. No doubt there is something very simple behind this. Anything obvious to check ?
George

gpontis

Beginner

Date of registration: Dec 18th 2007

Posts: 44

Location: California

2

Friday, October 13th 2017, 7:10pm

I should add that the fault does not occur when running in the simulator

gpontis

Beginner

Date of registration: Dec 18th 2007

Posts: 44

Location: California

3

Friday, October 13th 2017, 8:36pm

And also that it fails the same way with the Atmel SAME70 Xplained demo board. The fault occurs on a pop.w { r4-r11, pc }, but memory where sp is pointing is all 0. In fact that area of memory has been all 0 since entering main. It looks like the memory is not being written. For example, in the corresponding push.w { r4-r11, lr } the affected memory is not changed after the instruction executes, and at least the LR is not zero.

gpontis

Beginner

Date of registration: Dec 18th 2007

Posts: 44

Location: California

4

Friday, October 13th 2017, 9:30pm

Mystery solved. GPNVM bits 7, 8 in micro were set to map 128K of RAM to ITCM and another 128K to DTCM. That left only 128K available for program RAM, stacks, data. The startup code assumes that the caches are not used at all, so all 384K RAM would be available, and sets the stack pointer at 384K above the ram starting address. The micro specifically does not generate an exception when trying to access RAM that does not exist, unless the MPU is programmed to do so.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 434

5

Tuesday, October 17th 2017, 9:18am

Hello George,

Sorry for the delay in response.
Thank you for pointing this out. The Sample Projects are derived from the CMSIS packs for the MCU vendor.
Currently there are no "fixed" CMSIS files available. We will bring this to Microchips attention and update to the new packs once available.

Sorry for any inconveniences caused.

Best regards,
Nino

gpontis

Beginner

Date of registration: Dec 18th 2007

Posts: 44

Location: California

6

Thursday, October 19th 2017, 8:11pm

Thanks for looking at this. FYI, the way that Atmel handles this in their Studio is to simply set the top of RAM at 128K. That will always work for a demo, even if the GPNVM bits configure 128K each for DTCM and ITCM.
George

markuskrug

Beginner

Date of registration: Oct 19th 2016

Posts: 11

7

Thursday, November 9th 2017, 6:30am

Hello everybody,

I experienced the same problem. Does that mean the startup code needs to be modified to change the GPNVM bits? I would appreciate if someone can post a working example.

Best Regards
Markus