This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: not possible to have a ROM app that's started by system w/ Redboot?
- From: "Ken Yee" <kenkyee at excite dot com>
- To: ecos-discuss at ecos dot sourceware dot org
- Cc:
- Date: Mon, 08 Oct 2012 18:40:25 -0400
- Subject: Re: [ECOS] not possible to have a ROM app that's started by system w/ Redboot?
Iliya wrote:
> Yes, enable the respective tty<n> driver and set it as a console
> (default is ttydiag).
> But, actually you may have hardware problem (does it print barebone?).
Yes, it prints barebone (i.e., run as RAM startup type w/ Redboot). These are only issues w/ trying to get it to run as a Redboot Flash app (the new Redboot ROM app startup type instead of the existing eCos ROM startup type).
FYI, for the diag_printf issue of it going into space on the IF_COMM_PUTC, the problem was the app didn't have "claim comms virtual vectors" checked under the configtool under eCos HAL, the ROM monitor support. We got a lot further after checking off "claim virtual vector table entries by default", "claim reset virtual vectors", "claim delay_us virtual vectors", "claim data virtual vectors", and "claim comms virtual vectors". It's interesting that the app's ecos config had to be set to do that instead of letting it use the Redboot vectors automatically, so it seems like we missed a section define somewhere that tells the RAM startup type to use the redboot virtual vector table...
So next issue we've hit is JFFS doesn't read the Redboot FIS table properly so it can't figure out where the internal flash partition is that it's supposed to use...it's progress at least :-)
--- Begin Message ---
- From: Ilija Kocho <ilijak at siva dot com dot mk>
- To: Ken Yee <kenkyee at excite dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Fri, 05 Oct 2012 20:57:03 +0200
- Subject: Re: [ECOS] not possible to have a ROM app that's started by systemw/ Redboot?
- References: <20121005141943.18945@web007.roc2.bluetie.com>
On 05.10.2012 20:19, Ken Yee wrote:
>> It's true for break points. The target code being in Flash, rather than
>> RAM, needs hardware break points that are not supported by RedBoor/eCos
>> GDB stubs at present.
> I'm actually using a Segger JLink for debugging...not using Redboot's gdb support.
> That's why I'm puzzled...I should be able to look at the code behind that macro or single step through the assembly code but I can't do anything w/ that IF_PUTC function.
Then I'm afraid I can't help you much. I would check whether the GDB
server is set for hardware break points.
>
>> Try the real (instead of diagnostic) serial driver.
> Is there a way to get "diag_printf" to use the real serial driver? Interesting that you hit the same issue...I always thought the diag_driver just used the same serial port but with interrupts disabled.
Yes, enable the respective tty<n> driver and set it as a console
(default is ttydiag).
But, actually you may have hardware problem (does it print barebone?).
If you power Kwikstik from it's own USB connector there is a voltage
drop on serial diode (I don't recal whether it was D6 or D7) that
hinders RS232.
Ilija
IChYMTE7I!!
--- End Message ---
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss