TM4C1294NCND & Boot Loader erasable page size = 2K?

Hello Brett

Which example code are you referring to for bl_config.h? The readme and files for TM4C129 boot code has updates for TM4C129 as per 16KB page size

C:\ti\TivaWare_C_Series-2.1.0.12573\examples\boards\dk-tm4c129x\boot_emac_flash

Regards

Amit

 16KB page size   Aren't page size always described as bytes not bits?

EK-TM4C1294XL (bl_config.h) has erasable page size set at 1024 bytes, 0x00000400. Again the TM4C1294NCND data sheet states not possible to erase but a 2Kbyte page at any time. Not knowing the BL code extremely well beyond its application function makes me unsure what effect this page size actually has. The BL does FTP transfer of the application to flash memory, erasing only necessary pages, believe this may be why size does matter. Attached is the bl_config.h found in the \boot_loader root.

2541.bl_config.h

The EK-TM4C1294XL Boot Loader was packaged under:

C:\ti\TivaWare_C_Series-2.1.0.12573\boot_loader.

BTW: Has TI shipped any higher silicon above Rev1 to anyone? Asking because the errata found in revision 1 silicon  PWM can not trigger ADC (SSS) start sample sequence and wouldn't you know it that effects motor control. The one Mouser shipped me is Rev1 silicon and can not be used to migrate M3 to TM4C. :(

That was my bad, renamed (*.tmpl) figured was named (temp) by mistake, might explain why CCS5 suggests symbols not found during linking.  Attempting to migrate Boot_Eth project which links all BL c files from RDK v10636 where it had Ethernet transport assigned in bl_config.h . So far the only difference was bl_enet.c is now bl_emac.c , expected some issues in this area.

The RDK Ethernet GUI allows flashing of the target from a *.bin file using FTP transport in BL. Hope that remains constant until finished moving a few RDK functions into the cloud, time sharing the Ethernet between web and original GUI or use GUI composer with ICDI might prove more prudent. Added CPU utilization into the cloud last night and found it not to difficult, do for see the collective growing beyond 542 near future.

Not yet. _ This is odd news after seeing revision 5 silicon somewhere in documents at TI. Do you know if there is a work around for the errata PWM0 not able to trigger ADC0_1-3 SSS

Anyone interested this is where to find the revision level adding minor and major together.

Boot Loader compiled without error after renaming the (bl_config.h.tmpl) which also had the page size set 1024 bytes.

Seemingly the single erasable page size 2 x 8KB sectors or 16Kbyte Block % 8bits = 2kbyte page size (0x000007D0).

Thanks Amit :)

The TM4C1294 errata sheet suggest rev. 3 silicon is, has been in production. Unsure rev.1 will synchronize PWM counters when dividing SYSCLK @120Mhz. Using PWMDIV=%2 on PWM0 peripheral block, the 60Mhz clock renders 3000 ticks/sec. That alone introduce other issues when LM3S8971 50Mhz SYSCLK was used as the PWM clock with out PWMDIV. Mouser claimed were a brand new TI shipment of EK-TM4C1294Xl board, was fearful to find revision 1 chip. Have asked Mouser to ship a higher revision EK board as they could only provide the manufacture date which was later found to be March 2013, far existing from a new batch.

Do you know if errata (yellow box) was random among certain production runs and may not effect all chips in revision 1 class? Would think testing for errata among production runs does not test every chip made, TI may only test 500 out of every 5K produced.

Literature Number: SPMZ850B

October 2013–Revised March 2014

Hello cb1_mobile,

The 2K is 2048 bytes as you mentioned. There is no 0x7D0 for 2K (decimal) representation. I am not sure why the poster mentions it as 0x7D0.

Regards

Amit

Then revision 2-3 are experimental?  One would not easily draw that deduction from the sheet columns 2-3.

BTW: Poster stated 7D0; The datasheet shows an even 16KB block but had already deduce page size 800h or 2048 would be better choice. CB1 beat poster to the correction. That doesn't preclude the fact (bl_config.h.tmpl) suggests a 1024KB page size and the Tiva Boot Loader PDF shows (bl_config.h). Not trying to be anal retentive in this statement however "That which is gibberish translates in the very same way it is read" especially this shop. :) 

Per Boot Loader PDF:

SW-TM4C-BOOTLDR-UG-2.1.0.12573.pdf  Quote: The Ethernet controller will be configured to use the MAC address stored in the USER0/UART1 data registers or the MAC address that is provided in the boot loader configuration file (bl_config.h).

@ Amit,

Would you be so good as to give a second look @ my 10:45 posting, earlier today.  (I've slightly re-worded to better frame the critical PWM issues befalling o.p., my group, & most likely multiple others... )  The language in the PWM Section of this MCU's errata is sufficiently vague as to cause the o.p. to describe the errata's impact as, "random." 

Does not this lack of errata specificity potentially raise - or at minimum contribute to - the creation of, "false hope?"  (i.e. user's may attempt to weave their way "around" errata's, "under certain conditions" and, "may nots" - expending time, effort, funds in that process.)    Is this ideal - is this proper?  (and what if the factory "corrections" are not, "ready by the suggested 2Q-14 promise date?)

Would it not be much better if the more complete, "inside info" - known by you to invoke each PWM errata condition - were instead shared with motivated users - rather than held strictly w/in headquarters?  The efforts of multitudes here may even assist and/or speed your firm's resolution of that errata - especially if the likely, "errata trigger events/conditions" were, "made clearly known."  Seems more, "win-win" than present method's, "hint but obscure" - don't you agree?

Thank you...

Hello cb1_mobile,

I agree, that the information may be pretty vague to a user as it does not mention the conditions under which the interrupt and trigger may not be generated, But considering that it is a basic requirement from the PWM that the interrupt ought to be working it was thought to be sufficient.

I will check with the team if there could be a better description to this.

Regards

Amit

Once again - your responsiveness, caring & expertise shine through.  Thank you, Amit.

PWM generation and its normal/customary off-shoots (i.e. interrupts, triggers & fault management) are crucial to so many designs - and so many here - clearly this vague errata listing (hi-lighted by o.p.) deserves better treatment.

And - as earlier stated - perhaps the multitudes here - some motivated, skilled, under time-crunch (i.e. desperate) may just discover  successful, "work-arounds" - enabling at minimum - some PWM recovery far earlier than the release of "next/hopefully corrected" silicon!   (perhaps not as far-fetched as some think - such, "user-fix" has occurred multiple times in the past!)   Enlightened semi firms "tap" this "free resource" - if they can (somewhat) overcome, "NIH" bias...

Thanks again - quite the resource you are proving...  (do note that my efforts/voice target what I trust to be, "constructive issue identification" & alternative (sometimes imaginative) methods of resolution...)

But considering that it is a basic requirement from the PWM that the interrupt ought to be working it was thought to be sufficient.

Believe it was also BP101 who inquired about silicon revisions for this very reason prior to purchase of EK-TM4C1294lx desired for the launch pad X11 and Internet of Things Cloud management alerting of ADC events gone all wrong.

That was a long shot taken, errata; PWM0 dysfunctional triggering an ADC interrupt signaling start of sequence.

Timing the zero cross over points in a trapezoidal wave form require ADC monitored BEMF signals to be in sync with PWM commutation or FOC would become dysfunctional and provide useless rotating flux in a BLDC rotor. The outcome, a vibrating rotor great for aches pains or if one should sit upon such errata the imagination is limitless.

Hi Amit, Sounds as if you imply the TM4C1294NCPDT is not a production chip installed on EK-TM4C1294XL board.

TM4C— Production version of the silicon die that is fully qualified.

Have not yet introduced PWM drive code to TM4C1294NCPDT. Merely researching the what and why prior being slammed down on tracks, freight train so ruthlessly taking final breath.  

Hopefully PWM peripheral functions in revision 1 silicon will be less erratic than experimental silicon versions (XM4C) fully tested prior to production of revision 1 silicon. The errata sheet covers silicon revisions 1-3 any of which could have been experimental silicon discussed in the errata document for any chip in the TM4C129x family.

One can easily draw onerous conclusions due to the lack there of pertinent data being left from intellectual disclosure documents.

Should PWM0 errata become an issue there is a work around or idea that just may provide a 100% reliable alternative to using PWM0-Gen0 comparator zero count interrupt and ADC trigger pulse. The potential diverted any PWM0 erratic interrupt being left for road kill in a one track highway to hell should documented errata actually persist.

Possibly via one Timer put to use monitoring PWM0-Gen0 High/Low side output pins, input as separate CCP timer A/B events the train wreck can be diverted to a friendlier track, less the road kill is persistent beyond those bounds.

Perhaps the TI Gurus can add a workaround to the PWM errata document after all?

Crazy Generous!

1/3/2015 -- Yes & No;

TivaWare_C_Series-2.1.0.12573 (flash.c) (bl_flash.c) force entire 16KB to be erased prior to flashing 512 byte packet block Software Boot Loader.

The erase page block size of Stellarisware was previously 1024 bytes (0x0000.0400) for the same 512 byte packet block to be flashed.

Brett,

Amit's quite right - adding the "fine granularity" you (seem) to seek requires more (internal) MCU address lines - and decodes - surely adds complexity & cost.  And - if you follow (other) ARM MCUs (as we do) you'll note this "wider" page size is a notable trend - not unique here.

Change is (not always) wonderful - you may consider (bit warmer) embrace...

BP101 said:

LM FLASH appears to allow erasing only the necessary pages inside a 16KB sector prior to a write.

Mon (much tormented) ami,

Before your, Amit's & this reporter's head (all) explode - how do you note (ideally confirm) that (suspect) reduced page-erase, "appearance?" 

Would it not be quick, relatively easy for you to first "seed" several unique data patterns (even 4-8 bytes should work) w/in multiple of your (hoped for) 2KB, adjacent, flash sectors?  (suggest that you seed all 8 of those 2KB flash sectors)  And then - cause vaunted (all knowing) LM Flash to generate it's "wondrous, narrow-band, erase capability?"

I'd place tall stack of chips upon (all 16KB) of TM4C1294NCND "LOSING" your earlier - pre-seeded, test data.  And - such would be far stronger than a "hunch" or any "appearance."  Evidence has strict rules of admissibility & usage w/in the courtroom - proves most powerful.  "Appearance" - on the other hand - falls far down the scale...  (ever noticed how many - dressed to the nines - still are convicted?   So much for "appearance!")

Suggested test is quick/easy - and should bring your understanding into agreement w/Amit's guidance - despite what you (thought/imagined) you (once) saw!

Court (of public opinion) here duly notes that you've "passed" upon the chance of confirming the claim you made (and continue to make) for LM Flash.  Test is quick/easy - and my money's on Amit's guidance - not some "appearance."   (nice suit - btw - but you're still, Guilty!) 

One more thing dawned on me after thinking a bit more this situation. This poster only seeks to alert TI professionals something is not as it would be expected.

TM4C1294 Tivaware (flash.c - bl_flash.c) may have an issue to address across a constrained sector boundary during page erase or writes. LM-Flash Programmer does not have any such problem erasing only (necessary) pages or writing bytes across 16KB sector boundaries. With roughly 62 sectors 1024KB flash memory, Tivaware (flash.c) should be able to erase & write blocks across any constrained sector boundary. So in effect flash erase pages have become entire sectors in this issue.

Do believe LM-Flash Programmer ruled out TM4C1294 flash schema being faulted in this bout, he can wait in corner for the next bell ring.