New PIC32MZ DA

[Moondeck]

Hi everyone
I saw some info about the new PIC32MZ DA familly here: http://www.microchip.com/forums/m887839.aspx but the link to the datasheet seems to be dead (both of them).
Does anyone have it? Or at least some info?

Thanks, Moondeck

[Maxlor]

I'm kinda late to this thread, but I did just come across this presentation: http://www.microchip.com.cn/community/html/university/plan_3_3/005.pdf

Does look like an interesting chip, what with the 32MB of RAM and some graphics support built-in. Although seeing how ambitious it is (first time Linux support too), it'll probably be a while until it's matured to the point where it's not a constant source of frustration.

[bktemp]

The Chinese version of the datasheet seems to be available:
http://www.microchip.com.cn/community/Uploads/Download/Library/60001361b_cn.pdf

Embedded 32MB DDR2 SDRAM and the display controller look promising. But we probably need to wait another couple of years until it becomes useable.

There is still no useable documentation/app notes for the older PIC24 DA version telling all the details about the display controller, the GPU and how everything works together and what's the maximum supported display size.

[mikeselectricstuff]

AFAICS there is no embedded DDR2, just a DDR2 controller on some versions that can support up to 32MB, looks like it's mainly aimed at graphics as it shows a GPU connected to the controller.

[mikeselectricstuff]

Just looked at the presentation and it does show onboard DDR2 - this wasn't clear from the Chinese datasheet. Probably a multi-chip module if so.

[Yansi]

I have tried translating parts from the first page of the datasheet - it said "interface", not "embedded DDR2 memory". I think you still have to connect it from the outside. And 32MB is pretty limited for a controller though...

[bktemp]

Translate the "DDR2" columns on page 2:
For the smaller package it says internal, for ther larger external. It is also noted on page 605.
I hope this is true, because that would be really great having a lot of fast memory embedded in a quite powerful controller.

[benSTmax]

Seems like they have ported U-Boot for a presumed PIC32MZ DA Starter kit
http://lists.denx.de/pipermail/u-boot/2016-January/239901.html

and ported U-Boot here:
https://github.com/purna-mandal/u-boot/tree/pic32-upstream-v2

Maybe the DDR2-related source code would reveal more info

[benSTmax]

I also found this presentation in russian. Luckily we have Google translate 
http://gamma.spb.ru/media/pdf/masters2015/N32.pdf

Slide 18 tells about 32MB DDR2 included on the chip

[batteksystem]

Translate the "DDR2" columns on page 2:
For the smaller package it says internal, for ther larger external. It is also noted on page 605.
I hope this is true, because that would be really great having a lot of fast memory embedded in a quite powerful controller.

From the Chinese datasheet what I get is up to 32MB internal DDR2 and up to 128MB external. I think you don't need an internal DDR2 interface, if it is there, the chip should also be there, but could be a separated die wire-bonded internally.

Some Chinese lesson:
??external
??internal
??interface

[andersm]

Microchip managed to leak the preliminary English-language datasheet themselves, but I don't know if it's still available anywhere (DS60001361B, 60001361B.pdf). It basically says what you already figured out - the 169- and 176-pin devices can have a 32MB DDR2 memory embedded in the same package, while the 288-pin chip can use external DDR2 SDRAM memory.

[Howardlong]

Nice that there's still an LQFP package for quick prototyping and evaluation purposes.

[Howardlong]

One further comment: considering how long these devices are taking to be publicly available, I am wondering if Microchip are spending time getting the silicon right? Following the PIC32MZ EC series, one would hope they are, a lot of people (including me) lost a lot of confidence what with the awful silicon and a <10% completed software framework.

[Maxlor]

One further comment: considering how long these devices are taking to be publicly available, I am wondering if Microchip are spending time getting the silicon right? Following the PIC32MZ EC series, one would hope they are, a lot of people (including me) lost a lot of confidence what with the awful silicon and a <10% completed software framework.

I don't see it why it should be any different this time around, but how is it a problem? Just don't be so foolish to design the chip into a product right from the first silicon revision. Usually by the third (external, that is) revision the most egregious problems are fixed and the chips are mostly fine. And meanwhile, you have plenty of time to evaluate the chip.

[Howardlong]

One further comment: considering how long these devices are taking to be publicly available, I am wondering if Microchip are spending time getting the silicon right? Following the PIC32MZ EC series, one would hope they are, a lot of people (including me) lost a lot of confidence what with the awful silicon and a <10% completed software framework.

I don't see it why it should be any different this time around, but how is it a problem? Just don't be so foolish to design the chip into a product right from the first silicon revision. Usually by the third (external, that is) revision the most egregious problems are fixed and the chips are mostly fine. And meanwhile, you have plenty of time to evaluate the chip.

I don't know if you were unlucky enough to have had any direct experience of the PIC32MZ EC, but it was as if Microchip were in denial over it. In no way, for example, can they _ever_ have tried or tested, let alone characterised the ADC on those devices until many months after initial release. Its simultaneous sampling 28MSa/s 12 bit ADC was a key differentiator for this device, a key selling point. As time went on, its specifications eroded further and further. The best they can do is it's now a single S&H 8 bit 66.6kSa/s ADC.

The more recent PIC32MZ EF, though, has been a far better device in terms of bugs, and the ADC actually works. A pity it's still held back by a barely half finished bug ridden software framework though.

[JPortici]

One further comment: considering how long these devices are taking to be publicly available, I am wondering if Microchip are spending time getting the silicon right? Following the PIC32MZ EC series, one would hope they are, a lot of people (including me) lost a lot of confidence what with the awful silicon and a <10% completed software framework.

I don't see it why it should be any different this time around, but how is it a problem? Just don't be so foolish to design the chip into a product right from the first silicon revision. Usually by the third (external, that is) revision the most egregious problems are fixed and the chips are mostly fine. And meanwhile, you have plenty of time to evaluate the chip.

I don't know if you were unlucky enough to have had any direct experience of the PIC32MZ EC, but it was as if Microchip were in denial over it. In no way, for example, can they _ever_ have tried or tested, let alone characterised the ADC on those devices until many months after initial release. Its simultaneous sampling 28MSa/s 12 bit ADC was a key differentiator for this device, a key selling point. As time went on, its specifications eroded further and further. The best they can do is it's now a single S&H 8 bit 66.6kSa/s ADC.

The more recent PIC32MZ EF, though, has been a far better device in terms of bugs, and the ADC actually works. A pity it's still held back by a barely half finished bug ridden software framework though.

looks like they made a deal with the devil  let alone the soul of all those poor engineers who had to use the PIC32MZ EC

[andersm]

I don't know if you were unlucky enough to have had any direct experience of the PIC32MZ EC, but it was as if Microchip were in denial over it.

It would be interesting to know the full story, but seeing as it was pushed out the door just at the end of the year, I still suspect that Microchip either had some contractual obligations, or that some exec's Christmas bonus depended on it.

[benSTmax]

I still suspect that Microchip either had some contractual obligations, or that some exec's Christmas bonus depended on it.

And then Microchip bought Atmel and suddenly this chip was too weak when compared with SAMD series ... 

[tszaboo]

I always wonder, why is it soo difficult to include a SPI Flash (or better, QSPI) and a large size SDRAM into a microcontroller. Then you can make two layer PCBs with the microcontroller running at 100+MHz having megabytes of memory, and doing it's stuff.
I mean the price of 32MB of RAM and Flash is around 1.5 EUR. Surely it is valid request to have it built in in a 7-10 EUR MCU. I wont even mention the prices of some Cortex A5 or ARM7 microcontrollers is the same (running 4-5 times the speed) as the usual Cortex M4/PIC32.

[nctnico]

Still.. what do you want to do with only 32MB of memory? Run Linux? By the time you have a buildroot image ready for such a small device you'll find it won't be enough for having a decent GUI and going for a real SoC like TI and Freescale are offering makes much more sense. Sure for a high volume product it may make sense to try and cut costs but this market segment is extremely competitive with many players.

[mikeselectricstuff]

Still.. what do you want to do with only 32MB of memory?

Hi-res video screens for a nice UI. 

[nctnico]

Still.. what do you want to do with only 32MB of memory?

Hi-res video screens for a nice UI.

That sounds nice in theory but in order to create a nice UI quickly you'll need a GUI framework, graphics accelleration and that quickly adds up to using Linux + X-Windows. Ofcourse it can be done with less memory but it will take a lot of development effort and/or paying a lot of cash for a commercial GUI framework.

[bktemp]

I always wonder, why is it soo difficult to include a SPI Flash (or better, QSPI) and a large size SDRAM into a microcontroller. Then you can make two layer PCBs with the microcontroller running at 100+MHz having megabytes of memory, and doing it's stuff.

I did always ask the same question. All the DDR stuff is only necessary because you need a fast interface between the external memory and the CPU. If the memory is embedded on the same chip, you don't need any fancy interface with controlled impedance lines and other complex stuff. You can connect it directly to some 32/64/128bit wide memory bus lines using short bond wires or run it at many 100MHz or even GHz.

Still.. what do you want to do with only 32MB of memory?

Even Win98 needed less memory, so "only 32MB" sounds a bit harsh for a single chip controller with embedded memory.
If you need an application processor for some complex and memory intensive stuff, you can use the larger package variant and add 128MB external DDR2 SDRAM.
For a typical user interface 32MB are enough for nice animated menus.

[andersm]

All the DDR stuff is only necessary because you need a fast interface between the external memory and the CPU. If the memory is embedded on the same chip, you don't need any fancy interface with controlled impedance lines and other complex stuff.

I've always heard that DRAM uses different manufacturing processes, and can't easily be integrated on the same die. The PIC32MZ DA, for example, uses a stacked die. Also, why lower your yield when RAM is such a high-volume commodity product?

[tszaboo]

All the DDR stuff is only necessary because you need a fast interface between the external memory and the CPU. If the memory is embedded on the same chip, you don't need any fancy interface with controlled impedance lines and other complex stuff.

I've always heard that DRAM uses different manufacturing processes, and can't easily be integrated on the same die. The PIC32MZ DA, for example, uses a stacked die. Also, why lower your yield when RAM is such a high-volume commodity product?

Because it triples your board space and doubles or even triples your layer count. It doesnt need to be on the same die. These MCUs are also made on older 90 ish nm processes. 32MB of memory is plenty. And we are talking about microcontrollers, which dont have MMU, so no linux here, no bloatware, just C code doing big things.