This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Issue 1001132] New: porting to Atmel SAM3U


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]