• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 893 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Best Development path with DaVinci 3730

William Williams
Intellectual 430 points
Other Parts Discussed in Thread: DM3730

My target: DaVinci DM3730 on a Gumstix Overo® IronSTORM-Y COM ( https://store.gumstix.com/overo-ironstorm-y-com.html ) connected to a Tobi ( https://store.gumstix.com/tobi.html ) expansion board with 70-pin AVX connectors.

My Host: Window 7 Enterprise 64bit intel I5, running Oracle VBox with debian 8 (Jessie)  uname -a:

Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) x86_64 GNU/Linux

My development goal: is to be able to write low-level test functions that will test each system module (GPMC, SDRC, i2c, spi, uart..) and each external device (NAND, Eth, uSD...) while the DM3730 processor is in a heavy ion field. I was told that running Linux or any OS is not a good idea while trying to determine number of errors per full particle spill.

I've come across some good info on TI website but I am uncertain how to proceed. I would like to proceed with a no-OS solution if possible but not sure if I can do so and still run in the Gumstix environment. I may be limited to using Linux however I need to be able to get as low-level as possible and still have TI software examples.

What I would like: Use debian 8 environment, use CCS, have DM3730 starter software provided, I am accustomed to have TI provided system, subsystem device drivers (msp430, c2000, rm48..)

Am I asking for too much?

If so, how would you recommend I proceed?

Is there a roadmap?

Thanks!

  • 0
    TI__Guru 65405 points
    Hi William,

    I can not suggest you an universal decision or road map about how to proceed but you could minimize the effect of Linux OS by writing your testing tool in uboot or using Starterware (Currently there is no support for DM3730 but there is for AM335x, which is based on ARM Cortex-A8. As DM3730 is also based on ARM Cortex-A8 core, I hope you will be able to reuse some code from StarterWare for AM335x.)
    For more details look at:
    e2e.ti.com/.../207425

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Intellectual 430 points
    Tsvetolin,

    This is very appreciated!!! This has most likely saved me a great deal of time, I spoke with a colleague of mine, he is the one that recommended that I go to a no-OS solution for errors and an OS solution for latch ups. When looking for SEU’s, it is assumed that there is only 1 sensitive volume in a part and we are counting the number of errors per test run. With the OS/Application, we are looking for latch-ups mostly, as well as, SEU's. He said that he had an OMAP processor, he had written no-OS functions but did not believe that would help me. Well most OMAP processors its appears are based on ARM Cortex-A8. So... Now I will go back to him to request a reuse software transfer with justification!!! This is a great suggestion!

    Thanks!
    William