stm32f4 flashing with gdb failure

[Juan Solano]

Hi all,

I am unable to flash the sample applications using gdb. I am trying hello.exe, 
with a Nucleo stm32f429zi board, connecting through a Black Magic probe:

(gdb) load
Loading section .start, size 0x270 lma 0x0
Load failed

info mem in gdb shows 0x800 flash regions but does not show any ram in 0x0

Furthermore, the stm32f4 bsp linkscmds.stm32f4 file shows:
RAM_INT : ORIGIN = 0x2000, LENGTH = 128K
ROM_INT : ORIGIN = 0x, LENGTH = 1M

There is no reference to flash origin, which in this processor is in 0x800 
but aliased to address address 0x (BOOT0 = 0).

Any ideas?
Juan.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What are level in the thread?

[Joel Sherrill]

On Sat, Dec 5, 2020, 12:15 AM Richi Dubey  wrote:

> I tried searching it on Google and RTEMS Documentation, but couldn't find
> anything that explains this.
>
> On Sat, Dec 5, 2020 at 11:34 AM Richi Dubey  wrote:
>
>> Hi,
>>
>> Can someone please help me understand what is meant by level? What is
>> meant by the dispatch level and the pin level and other such definitions? I
>> just want a high-level idea of what we achieve by having levels and why we
>> need them.
>>
>
This is a critical section which prevents thread context switches from
occurring while the dispatch level is not zero. This is generally used so
dispatching is deferred until the end of operations. It is also used so we
do not attempt to switch to another thread while in the middle of an
interrupt service routine

I would think this was documented somewhere but honestly I don't know
where.  If someone has a suggestion , then we should add it.

It would seem that we need a discussion of the types of critical sections,
when they are used, and the difference between uniprocessor and symmetric
processing configurations.

>
>> Why do we have:
>>
>>  _Assert( cpu_self->thread_dispatch_disable_level == 1 );
>>
>> in some codes?
>>
>
This means that the software should not be called when dispatching is
disabled. This may mean not from an interrupt service routine although that
is by implication since you could have checked the interrupt nest level.
This can prevent some methods from being called from a user extension.

--joel

> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Which threads execute _Thread_Handler ?

[Joel Sherrill]

On Sat, Dec 5, 2020, 12:14 AM Richi Dubey  wrote:

> Also,
>
> The stack trace for the thread looks like this:
>
> Tasks (entry function) -> rtems_task_wake_after ->_Thread_Dispatch_direct
> -> _Thread_Do_dispatch (where the _Context_switch function call lies), how
> can then the heir thread start executing from the _Thread_Handler? I do not
> see it in the trace at all.
>

Maybe the stack trace isn't right. I saw case this week where the stack
trace during system initialization doesn't work at all on a sync qemu.

I'd recommend setting a breakpoint at thread handler and at the entry point
of each of the threads just to confirm that what is supposed to happen is
actually happening.

--joel

>
>
>
> On Sat, Dec 5, 2020 at 11:05 AM Richi Dubey  wrote:
>
>> I have currently no time to help you debugging this issue.
>>
>> Okay, even a hint would be helpful.
>>
>> returns to _Thread_Do_dispatch() or jumps to _Thread_Handler().
>>
>> When does it return to  _Thread_Do_dispatch() and when does it jump to
>> _Thread_Handler() ? Is there a condition? How does it choose between what
>> to do?
>>
>>
>> On Fri, Dec 4, 2020 at 1:35 PM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> On 04/12/2020 08:56, Richi Dubey wrote:
>>>
>>> >
>>> > When I am trying to debug tm24 running on the Strong APA scheduler
>>> > code, I can see that the thread which comes after the call
>>> > to _CPU_Context_switch, resumes execution from the same code (next
>>> > line in the _Thread_Do_dispatch function after _CPU_Context_switch),
>>> > whereas when the same code is run on a different scheduler (the
>>> > default sp scheduler) the heir thread that executes after the call
>>> > to _CPU_Context_switch starts executing from  _Thread_Handler and does
>>> > not resume its execution from the _Thread_Do_dispatch (which has the
>>> > context_switch function call).
>>> >
>>> > Why is this happening? Is the scheduler responsible for this?
>>>
>>> I have currently no time to help you debugging this issue.
>>>
>>> Each thread starts the execution in _Thread_Handler(). A context switch
>>> returns to _Thread_Do_dispatch() or jumps to _Thread_Handler(). The
>>> _Thread_Handler() completes the context switch, does some general calls
>>> to begin the thread execution and then calls the thread entry function.
>>>
>>> --
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.hu...@embedded-brains.de
>>> phone: +49-89-18 94 741 - 16
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>>
>>> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel