<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>SPIM3 tx data corruption, byte carried over from previous operation.</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/118134/spim3-tx-data-corruption-byte-carried-over-from-previous-operation</link><description>NCS 2.7 
 NRF52840 
 SPIM3 at 32 MHz. 
 I have CONFIG_NRF52_ANOMALY_198_WORKAROUND=y and have confirmed the workaround is being activated by setting breakpoints in my code. 
 
 I am chasing down a NOR flash page program failure. I found the failure occurred</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 24 Feb 2025 22:09:29 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/118134/spim3-tx-data-corruption-byte-carried-over-from-previous-operation" /><item><title>RE: SPIM3 tx data corruption, byte carried over from previous operation.</title><link>https://devzone.nordicsemi.com/thread/524449?ContentTypeID=1</link><pubDate>Mon, 24 Feb 2025 22:09:29 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:e685c76d-6fed-40fe-8215-132daaace933</guid><dc:creator>Anthony Ambuehl</dc:creator><description>&lt;p&gt;I gave up and switch to the older/slower version of the SPIM peripheral.&amp;nbsp; If I have time and client is willing to pay I&amp;#39;ll spend time trying to figure it out.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: SPIM3 tx data corruption, byte carried over from previous operation.</title><link>https://devzone.nordicsemi.com/thread/519086?ContentTypeID=1</link><pubDate>Mon, 20 Jan 2025 13:45:27 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b617944a-283b-4012-a8ca-3a7b5fb61247</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;There are some unfortunate issues with SPIM3. In this case, I wonder if it would help to use double-buffering and ensure that the buffers are on separate RAM sections, as shown in &lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/113104/nrf52840-ble-causing-display-glitch-on-gc9a01-using-spim/495903"&gt;this post&lt;/a&gt;?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: SPIM3 tx data corruption, byte carried over from previous operation.</title><link>https://devzone.nordicsemi.com/thread/518918?ContentTypeID=1</link><pubDate>Fri, 17 Jan 2025 21:42:05 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a571922e-50d1-4188-818c-eafaafd8c86e</guid><dc:creator>Anthony Ambuehl</dc:creator><description>&lt;p&gt;To confirm that this is a bug with SPIM3, I switched to SPIM2 and have not been able to repeat the failure after many 10&amp;#39;s of minutes of testing.&amp;nbsp; SPIM3 usually fails within 4-8 minutes..&lt;/p&gt;
&lt;p&gt;I&amp;#39;ve&amp;nbsp;read multiple posts where people just give up on SPIM3 and switch to an older style SPIM with the 8 MHz limit.&amp;nbsp; Its frustrating to spend time on stuff that is clearly broken.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>