This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Issue 1001132] New: porting to Atmel SAM3U
- From: bugzilla-daemon at ecoscentric dot com
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Thu, 27 Jan 2011 06:50:57 +0000
- Subject: [Issue 1001132] New: porting to Atmel SAM3U
- Auto-submitted: auto-generated
Please do not reply to this email. Use the web interface provided at:
https://bugzilla.ecoscentric.com/show_bug.cgi?id=1001132
Summary: porting to Atmel SAM3U
Product: eCos
Version: 3.0
Platform: Other (please specify)
OS/Version: Cortex-M
Status: UNCONFIRMED
Severity: major
Priority: normal
Component: Kernel
AssignedTo: unassigned@bugs.ecos.sourceware.org
ReportedBy: rocendo.bracamontes@atmel.com
QAContact: ecos-bugs@ecos.sourceware.org
CC: ecos-bugs@ecos.sourceware.org
Class: Advice Request
Hi,
Recently we acquire a license for Ecos-Pro for the Atmel-ARM7 -SAM7S-, our
intent was to use the SAM7SE and Ecoscentric was tasked to enhance the SAM7S
port to SAM7SE. Unfortunately, later on, Ecoscentric decided that it was not
possible to do so.
That put us in a stress situation to deliver a hardware platform, due to the
time constraints, we need to deliver a new hardware soon, so we put aside the
SAM7SE and took the challenge to take the STM32 Cortex-M3 as basis for the
Atmel SAM3U4.
Since we have paid support, and it was unexpected the challenges encountered on
the SAM7SE, I would like to redirect the support to our current effort on the
M3.
I have taken the STM32 files and port mostly the initialization and CDL files
to reflect the ATMEL CM3 architecture. I'm not using Reedboot/ROM monitors. I'm
just trying to get the kernel up and running and download it to the Eval-Board
using JTAG.
I think I have done a good progress and the STM32 port is a great example to
follow. I can build the Ecos library using configtool and compile a basic
application containing 3 threads.
The *problem* I'm experiencing is that, when the schedulers starts, it executes
to the first thread but it never leaves that thread. When I added the
thread_delay(), at some point the execution gets lost.
I can see in the files cortexm/arch/v3_0/include/hal_int.h and
cortexm/arch/v3_0/src/hal_misc.c how the definition and setup of the
hal_vsr_table[] for exceptions and interrupts.
During debug I can see in memory mapped registers the system tick timer
counting and it was properly initialized. However the systick interrupt does
not seem to be set by HAL_CLOCK_INITIALIZE
I think my problem could be related to interrupts setup, but that is why I'm
asking for some hints.
Could you confirm if the scheduler uses a systick interrupt for context
switching, etc?
Could you elaborate how the systick interrupt is setup on the STM32 port (if
used) ?
Is there any specific function on HAL that is dedicated to the systick
interrupt? I could not find any specifcs, the systick interrupt gets a assign
to "hal_default_isr" on hals_misc.c
I appreciate your feed back, and I hope we can use the support credits for this
effort.
Thank you
Rocendo
--
Configure issuemail: https://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the issue.
You are on the CC list for the issue.