Associate II

Question

Internal SRAM write and read back problem

Forum|Forum|11 years ago
December 10, 2014
11 replies
2456 views

Posted on December 10, 2014 at 06:40

Hi, I've bought a STM32F4-Discovery board and trying to capture images from the camera. I'm trying to transfer the image to SRAM(112K) instead of LCD-RAM as given in the example code. After the data is read back from the SRAM and the image is seen, it just shows junk. I've checked the pins with a scope to ensure PIXCLK is running. I'm really unsure whether the camera data is being written into SRAM or not.

Can anyone help on this...

#dcmi-sram-bmp #dcmi-sram-bmp

DCMI

This topic has been closed for replies.

ivani

Visitor II

Posted on December 10, 2014 at 08:11

Does the image fit in the internal SRAM? What is the camera resolution and how many bits per pixel?

chaitanyaAuthor

Associate II

Posted on December 10, 2014 at 11:58

I've reduced the image size to fit in the SRAM 160x120(16bit)... The image is transferred from DCMI to SRAM through DMA. I'm doubting this part...

The image write routine reads the SRAM and puts in a BMP file... The image remains the same before image capture and after image capture.

ivani

Visitor II

Posted on December 10, 2014 at 12:58

So, may be something with DCMI, or DMA initialization?

Just for the test configure the DMA for a single transfer and check if the corresponding transfer complete flag gets set.

chaitanyaAuthor

Associate II

Posted on December 11, 2014 at 12:14

I'm using DMA circular mode. Anyways, I checked the flag and it shows the transfer complete.

ivani

Visitor II

Posted on December 11, 2014 at 12:51

So, may be the transfer happens not to the right location, or in a wrong direction?

Are you sure that the receive buffer is not altered after the DMA transfer? Initialize it with some known pattern and check it when the DMA ends.

Could it be that the garbage is coming from the camera?

chaitanyaAuthor

Associate II

Posted on December 12, 2014 at 19:54

This afternoon, I discovered that another array is using the same locations... I changed the location address but no luck... Will have to do the pattern test... Will update if I find the bug...

chaitanyaAuthor

Associate II

Posted on December 14, 2014 at 00:35

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6p5&d=%2Fa%2F0X0000000bwE%2F5LyGnYzRuJ.itkbLWMv6QcnCfTYk8OGKaWbpQCcXJMI&asPdf=false

ivani

Visitor II

Posted on December 15, 2014 at 20:15

Nothing special but I didn't see if you enabled the clock of GPIO and DCMI.

May be you did it before this code.

chaitanyaAuthor

Associate II

Posted on December 17, 2014 at 19:15

that's true regarding the clock...

There is an update... the HS needs to be chaged to Low as per the ov9655 datasheet... unlike the example code with HREF inverted... with me HREF inverted or normal does not have any change... only DCMI HS polarity is causing the data change... HS High is causing all pixels to be black...

As suggested.. I write a pattern and this gets replaced with the pixels.. the intensity is also changing with respect to light... I covered it completely and the image pixels are dark...but still garbage.... I've attached the images...

________________

Attachments :

Dark.BMP : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzyl&d=%2Fa%2F0X0000000bRh%2Fjz3AKOXIQYHxRnau6L5g2.LXP_76ayAkUiUqkIcvekM&asPdf=false

Light.BMP : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzyg&d=%2Fa%2F0X0000000bRg%2FOm.z69_DLN60zlYPiT94ofrH_1zf.RI5kNP4VQOdsRw&asPdf=false

Pattern.BMP : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzpk&d=%2Fa%2F0X0000000bRe%2FQzGou9Y0afLCs4eerNS4D_pPZbTFfHC5rxyZCUSzDM0&asPdf=false

ivani

Visitor II

Posted on December 17, 2014 at 20:28

It seems like a mismatch between input and output resolution in X/Y. Clearly, there is some correlation between pixels, not a chaotic image.