AnsweredAssumed Answered

SS for Sharc 3.9.0 and SC589 EzBoard version issues

Question asked by Brewster on Feb 2, 2017

I'm hoping ADI can shed some light on the underlying issues as I don't see why the hardware version is playing in to this.

The issue is more or less the same as occurred with SS for Sharc 3.7.0; BOM 1.5 hardware didn't work and BOM 1.6 hardware did, but the only difference was an (in consequential?) ferrite bead. Here's that one for those interested: assertion eRet == ADI_SS_FW_SUCCESS failed in CCES console 

 

I have SC589 EZ rev 1.1 BOM 1.6. I see in the SS4S 3.9.0 user guide that rev 1.2 BOM 1.8 is called out. And sure enough if I run the example in the user guide I get the same assertion eRet == ADI_SS_FW_SUCCESS failed error.

However if use the core executable files from 3.7.0, ...SigmaStudioForSHARC-SH-Rel3.7.0\Target\Demo\ADSP-SC58x\ADSP-SC589\SS_App_Core#\Release then the SS4S example runs fine, both from SS 3.12 and SS 3.14.

 

However if I diff the sources in SigmaStudioForSHARC-SH-Rel3.#.0\Target\Demo\ADSP-SC58x\Source the only difference is this added function call (and its supporting code, etc):

/* Flush and invalidation is required only when parameters are mapped to L3 memory,
cache is enabled and parameters are non safeload parameters */
adi_ss_flush_invalidate_Dcache();

This doesn't seem like something that should cause a hardware dependency so I'm thinking the difference is elsewhere but the only other thing I see is small changes in adi_ss_arm_fw.h and adi_ss_smap.h and they don't seem like a culprit. Of course there's plenty of things without source that might be different.

 

I then approached it from the hardware side and diff'd the rev 1.0 versus 1.1 schematics as I could not find a readme or revision control document that explained what the changes were or why they were made (something we would need when we start our own hardware design, but I know that's a question for a different group). There is a change to the memory design and maybe that explains why SS4S 3.9.0 app_core files won't work? The other changes don't seem like they would make a difference.

 

In summary, my questions are:

  1. Why won't the SS 3.9.0 generated project load with the app-core files on a rev 1.1/BOM1.6 board?
  2. What issue(s) will I have if I use the SS3.7.0 app-core files with SS3.9.0?
  3. Is there any alternative to getting yet another board "upgrade" (i.e. replace the board)?
  4. Or maybe rev 1.1/BOM1.8 fixes other problems and I should have one of those regardless of SS4S issues?
  5. Will the next SS4S version need yet a newer board (i.e. if I can run with the older files maybe I should wait until the dust settles)?

 

Thanks,

Brewster

(edited to correct hardware revision numbers)

(edited to add link to question asked in the hardware group:

Differences between SC589 EZ rev 1.1/BOM1.6 and Rev 1.2/BOM1.8 

)

(edited to add link to specific problem with BOM 1.8 board, which I did not have when the above was reported.i.e.  I had assumed the above was because I had a BOM 1.6 board, but as shown here that doesn't seem to be the issue: SS for Sharc 3.9.0 assertion eRet == ADI_SS_FW_SUCCESS on load  )

Outcomes