Thanks for everyone's help on this. All working now.
It transpires the msgram can be in SDRAM not just in ISRAM so the solution is
much more like the samV71 using cached memory, but it is handled a little
differently in a few places of course.
No thanks AT ALL to the Atmel datasheet which says:
On Tue, Jun 8, 2021 at 9:34 AM Tim Hardisty wrote:
>
>
> On 08/06/2021 14:18, Sebastien Lorquet wrote:
> > what I would check here (just a live thought process)
> >
> > * check that the ld file is actually used (ld file is pointed by main
> > Make.defs IIRC) (easy: just add garbage in it and verif
stm32h7/stm32_spi.c#L715-L716
> >>
> >>
> >>
> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
> >>
> >>
> >> You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mc
On 08/06/2021 14:18, Sebastien Lorquet wrote:
what I would check here (just a live thought process)
* check that the ld file is actually used (ld file is pointed by main
Make.defs IIRC) (easy: just add garbage in it and verify build actually
breaks)
You, sir, have earned the cigar! Garbage
nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
David
-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subj
lash.ld#L179-L184
You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
David
-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations
On 07/06/2021 19:06, Nathan Har
lash.ld#L179-L184
You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
David
-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations
On 07/06/2021 19:06, Nathan Har
Hello,
The correct syntax is:
.isramdata (NOLOAD) : /*<- this is the segment name in the output,
NOLOAD means that this segment is not to be initialized, like BSS, but
the linker alread knows that BSS is NOLOAD*/
{
*(.isramdata) /*<- this is the input sections from the
reloca
| grep g_mcan0_msgram
David
-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com.INVALID]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations
On 07/06/2021 19:06, Nathan Hartman wrote:
> On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
>>
On 07/06/2021 19:06, Nathan Hartman wrote:
On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.
Yes. It is possible. It is done by adding attributes in the code which
tel
On 07/06/2021 20:45, Gregory Nutt wrote:
I will, I believe, need to declare - place - MCAN related structures
such
that they (or at least some elements of them) are in SRAM.
You will need to exercise care. SRAM (called isram in the linker
scripts) is already used for other things including
I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.
You will need to exercise care. SRAM (called isram in the linker
scripts) is already used for other things including the MMU page table:
https://github.com/pa
On 07/06/2021 17:22, Tim wrote:
This is probably not really a NuttX question per se, but it relates to
getting the MCAN interface for a sama5d2 to work properly. And you are all
such knowledgable and helpful people :)
The MCAN controllers assume the base address of the message ram is at
0x2
On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
>
> This is probably not really a NuttX question per se, but it relates to
> getting the MCAN interface for a sama5d2 to work properly. And you are all
> such knowledgable and helpful people :)
>
>
>
> The MCAN controllers assume the base address of the m
14 matches
Mail list logo
