2009-04-20 09:13:11     SDGCTL value for CM-BF537E

Document created by Aaronwu Employee on Aug 15, 2013
Version 1Show Document
  • View in full screen mode

2009-04-20 09:13:11     SDGCTL value for CM-BF537E

Jean-Francois Argentino (FRANCE)

Message: 72873   

 

Hello,

 

I've made three different posts about problems I'm facing with several CM-BF537E:

 

Message #72705: "Missing hardware change on GPIO pin"

 

Message #72745: "sometimes the PPI DMA transfer never start"

 

Message #72701: "PWM_OUT mode fails with gptimer0 and gptimer1 on BF537E when CONFIG_HZ isn't 100"

 

The only way I found that greatly improves these three problems is to play with the SDGCTL register value. By increasing some of the delays, the two first problems I'm facing just disappear! The third one occurs after some millions transfers, wich is just far bigger than with the default SDGCTL setting). But the delays I'm setting are far over the delays recommended by MICRON.

 

Sadly, I can't go further to make disappear the gptimer problem since if I increase delays again (or decrease the system clock), I have PPI FIFO overflow error, I think it's normal since I downgrade the RAM performance.

 

I'm not sure how to interpret this, for me it looks like there's a big hardware problem with the SDRAM, and it's confirmed by the fact that the same software system works without any problem on older CM-BF537E boards.

 

I want some advices about this fact, and if there's another way (maybe u-boot based, or a stand alone program) I can quickly use to proove/unproove what I'm thinking.

 

More over, I'm not totally agree with the value I can read for these delays in the arch/blackfin/include/asm/mem_init.h file. The table 20 from the MT48LC16M16A2TG-75 datasheet (page 52) give me (cycles for SCLK=120MHz):

 

Tras = 44ns - > 6 cycles (7 cycles in the mem_init.h but I think bigger value just decrease perf)

 

Trcd = 20ns -> 3 cycles (2 cycles in the mem_init.h)

 

Trp = 20ns -> 3 cycles (2 cycles in the mem_init.h)

 

Twr = 1 CLK + 7.5ns -> 2 cycles

 

But maybe I understand something wrong, I didn't read the whole memory datasheet nor the whole EBIU HRM chapter.

TranslateQuoteReplyEditDelete

 

 

2009-04-20 09:40:17     SDGCTL value for CM-BF537E

Michael Hennerich (GERMANY)

Message: 72877   

 

I would check with the Bluetechnix Support, to see if they changed the SDRAM device.

Try to get the exact part numbers for the different revisions.

 

On this page you can find a spread sheet that calculates the SDRAM timing configuration registers for you.

 

  docs.blackfin.uclinux.org/doku.php?id=bfin:sdram

 

 

-Michael

QuoteReplyEditDelete

 

 

2009-04-20 10:03:42     Re: SDGCTL value for CM-BF537E

Jean-Francois Argentino (FRANCE)

Message: 72882   

 

Michael,

 

The SDRAM device is the same (mark on the component is D9DHT on all the boards I have).

 

I've seen and use the spreadsheet you're talking about, and the result it gives is different than the delays you can find in the mem_init.h.

 

In this spreadsheet, there's the comment for tRCDmin which says "ACTIVE bank a to ACTIVE bank b command", but I think that it's more revelant to be the "ACTIVE to READ or WRITE" isn't it?

TranslateQuoteReplyEditDelete

 

 

2009-04-20 10:25:52     Re: SDGCTL value for CM-BF537E

Michael Hennerich (GERMANY)

Message: 72886   

 

>and the result it gives is different than the delays you can find in the mem_init.h.

 

Consider the 'Re-program Clocks while Kernel boots' as EXPERIMENTAL

 

config BFIN_KERNEL_CLOCK_MEMINIT_CALC

bool "Calculate Timings (EXPERIMENTAL)"

depends on EXPERIMENTAL

 

Either specify correct values in u-boot (preferred) or use CONFIG_BFIN_KERNEL_CLOCK_MEMINIT_SPEC.

 

Regarding your spreadsheet questions - they author is currently on vacation.

I will forward your question.

-Michael

QuoteReplyEditDelete

 

 

2009-04-20 11:29:46     Re: SDGCTL value for CM-BF537E

Jean-Francois Argentino (FRANCE)

Message: 72895   

 

I see that it's an experimental option, and if I well understand it, it uses the value from the mem_init.h?

 

> Either specify correct values in u-boot

 

I just play with the CONFIG_BFIN_KERNEL_CLOCK_MEMINIT_SPEC so i'll try it through u-boot asap.

 

But the matter is to know if it's a normal behaviour that increasing the SDRAM delays far over the components recommended ones makes my problems desappear?

 

Are you agreed with me that it could be a hardware problem? If not, or if you have any other idea, could you please suggest me a tool, an easy test or anything that could point me to another way to look at.

 

PS: I'm in relation with bluetechnix support too, but the software engineer just come back today from hollydays...

TranslateQuoteReplyEditDelete

 

 

2009-04-21 06:49:54     Re: SDGCTL value for CM-BF537E

Michael Hennerich (GERMANY)

Message: 72937   

 

>I see that it's an experimental option, and if I well understand it, it uses the value from the

>mem_init.h?

 

Exactly

 

>But the matter is to know if it's a normal behavior that increasing the SDRAM delays far over the

>components recommended ones makes my problems desappear?

 

I wouldn't say at all that the issues you posted are normal.

 

Message #72705: "Missing hardware change on GPIO pin"

Message #72745: "sometimes the PPI DMA transfer never start"

Message #72701: "PWM_OUT mode fails with gptimer0 and gptimer1 on BF537E when CONFIG_HZ isn't 100"

 

Actually I never saw or ever head about similar things.

 

>Are you agreed with me that it could be a hardware problem?

 

Yes.

Do you see such things only one board? And do you have more to test with?

 

-Michael

QuoteReplyEditDelete

 

 

2009-04-21 07:40:44     Re: SDGCTL value for CM-BF537E

Jean-Francois Argentino (FRANCE)

Message: 72974   

 

> Do you see such things only one board? And do you have more to test with?

 

Everything works without these errors for duration of more tyhan 24h on two 2 years old CM-BF537E, and on 3 recents CM-BF537E. But, the same system image doesn't work on 8 others recents CM-BF537E... And that's on those boards that I've played with the SDGCTL register.

TranslateQuoteReplyEditDelete

 

 

2009-04-21 08:52:38     Re: SDGCTL value for CM-BF537E

Michael Hennerich (GERMANY)

Message: 72986   

 

>Everything works without these errors for duration of more tyhan 24h on two 2 years old CM-BF537E,

>and on 3 recents CM-BF537E. But, the same system image doesn't work on 8 others recents CM-BF537E...

>And that's on those boards that I've played with the SDGCTL register.

 

This indeed sounds very much like a hardware issue.

 

I think I saw CM-BF537 modules with the /BR (Bus Request) Pin floating.

According to the Blackfin datasheet "This pin should be pulled high when not used"

Can you check if this is still the case on your modules?

 

Also - in case you utilize the Async Memory Interface (EBIU) with the IORDY feature enabled make sure IORDY is in a defined state, during accesses.

 

-Michael

QuoteReplyEditDelete

 

 

2009-04-21 09:31:09     Re: SDGCTL value for CM-BF537E

Jean-Francois Argentino (FRANCE)

Message: 72989   

 

All the boards I have here have their /BR pin pulled-up by 10k, done on the tinyboard

 

I didn't play with the async memory interface, I keep the default values in the kernel configuration for EBIU_AMGCTL and EBIU_AMBCTL, excepting maybe for the C_CDPRIO which I could have set after having reading the PPI doku (but maybe it was done by default too? I can't remember).

 

But I can't find any IORDY in the HRM, do you refer to the ARDY?

TranslateQuoteReplyEditDelete

 

 

2009-04-21 09:38:30     Re: SDGCTL value for CM-BF537E

Michael Hennerich (GERMANY)

Message: 72990    >But I can't find any IORDY in the HRM, do you refer to the ARDY?

Blah - Yes

-Michael

 

QuoteReplyEditDelete

 

 

2009-04-24 14:36:24     Re: SDGCTL value for CM-BF537E

Mike Frysinger (UNITED STATES)

Message: 73178   

 

what are you plugging the CM-BF537E modules into ?  are they bluetechnix dev boards or your own hardware ?

 

can you post exact revision information for eacy core module and which ones work ?

QuoteReplyEditDelete

 

 

2009-04-27 09:46:53     Re: SDGCTL value for CM-BF537E

Jean-Francois Argentino (FRANCE)

Message: 73288   

 

We plug the CM-BF537E in our own hardaware, we have look at the power supply, they look good. The signals shared with the tinyboards come from a CPLD and a FIFO, both are near the tinyboard (about 5 and 3 cm respectively), no wires-connection. These signals look clean too, and the PPI clock is 12MHz "only"...

 

Following is my inventory, KO mean that quite quickly (some minutes) the internal frame sync signal never rise again. OK means that there's no problem for more than 12hours:

 

SN 1221-12-2380, board V1.2.5, DSP rev0.3 KO

 

SN 1221-12-2378, board V1.2.5, DSP rev0.3 KO

 

SN 1221-12-2377, board V1.2.5, DSP rev0.3 KO

 

SN 1221-12-2376, board V1.2.5, DSP rev0.3 KO

 

SN 1221-12-2370, board V1.2.5, DSP rev0.3 KO

 

SN 1221-12-2304, board V1.2.5, DSP rev0.3 KO

 

SN 1221-12-1866, board V1.2.4, DSP rev0.3 KO: didn't boot from flash anymore (boot mode 0) but boot OK from UART

 

SN 1221-12-2376, board V1.2.5, DSP rev0.3 KO: Can't erase flash sector 0, but can boot in mode 0

 

SN 11-0478, board V1.1, DSP rev0.3 OK

 

SN 11-0480, board V1.1, DSP rev0.3 OK

 

SN 1221-22-1399, board V1.2.4, DSP rev0.2, KO but works far more longer thant the other "KO" boards.

 

SN 1221-12-2373, board V1.2.P, DSP rev0.3: in test now, works for more than 2 hours, so I think it works.

 

SN 1221-12-2375 and 1221-12-2371 (board V1.2.P, DSP rev0.3) not tested since last driver and SDGCTL corrections but one of them must work.

 

A last remark, now that I've corrected the SDGCTL register, most of the boards that don't work when the DMA transfer isn't starting, the internal frame sync signal never rise again for the same transfer. But some boards still have these behaviour independently: tenth of DMA transfers can not be done until the internal frame sync never riise again...

 

 

TranslateQuoteReplyEditDelete

 

 

2009-04-27 13:55:46     Re: SDGCTL value for CM-BF537E

Jean-Francois Argentino (FRANCE)

Message: 73310   

 

As suggested, I've set the SDGCTRL register in u-boot but it doesn't change anything. Since my system doesn't use the flashmemory once booted, I disable all the banks in the kernel configuration, but that's not better. I don't have any idea now, and no news from bluetechnix...

Attachments

    Outcomes